AI agents are moving beyond generating responses. They can now interact with enterprise APIs, retrieve operational data, and execute actions through tools exposed using the Model Context Protocol (MCP).
This introduces an important security challenge: How do we ensure an AI agent executes only the operations it is explicitly authorized to perform?
Consider an AI agent responsible for monitoring application health. It may need to check service status and retrieve diagnostic information. But should it also be allowed to restart services or modify infrastructure?
A valid authentication token establishes identity. It does not automatically grant permission to perform every available action.
I built AgentTrust, an AI agent security reference architecture and implementation that explores how established Zero Trust principles—explicit verification, least-privilege access, and deny-by-default enforcement—can be applied to MCP tool execution.
AgentTrust demonstrates this principle through signed agent identities, trusted permission mappings, independent Gateway enforcement, and observable authorization decisions.
The implementation has been validated in a local environment. Its focus is on demonstrating the security architecture and enforcement mechanisms rather than providing a complete production authorization platform.
1. The Security Challenge: Controlling Agent Actions
Traditional applications typically invoke predefined APIs through known execution paths.
AI agents introduce a different interaction model. Depending on their instructions and available tools, they may dynamically select operations during execution.
An agent that normally performs read-only monitoring might attempt an administrative action because of an unexpected instruction, application behavior, or malicious content.
For example, an untrusted document or tool response could influence an agent to request a service restart.
Prompt instructions and application-level restrictions can reduce unwanted behavior, but they should not be treated as authoritative security controls.
The infrastructure protecting sensitive operations must independently evaluate whether the requesting identity has the required permission.
This requires three architectural properties:
- Explicit identity verification: Establish the authenticated identity associated with the request.
- Least-privilege authorization: Permit only operations covered by explicitly granted permissions.
- Pre-execution enforcement: Reject unauthorized operations before protected systems execute them.
AgentTrust applies these principles to a defined subset of MCP tool execution.
2. AgentTrust Architecture and Trust Boundaries
AgentTrust separates agent integration from authorization enforcement.
The architecture consists of five principal components.
External Identity Issuer
A trusted issuer creates signed credentials representing an agent execution context.
In Gateway mode, the issuer signs JWTs using Ed25519. The signing private key remains outside the public SDK and Gateway.
The Gateway verifies these credentials but does not issue them.
AI Agent
The agent represents an application or automated workflow requesting tool operations.
It operates in a less-trusted environment and cannot be relied upon to enforce its own authorization requirements.
Public AgentTrust SDK
The public Python SDK provides the integration client used to communicate with the Gateway.
The client supplies a bearer token, logical tool identifier, and JSON arguments.
It does not determine the required authorization scope or select the protected MCP destination.
The SDK also supports a separate cooperative local mode using HS256 tokens. This mode has a different trust model and does not provide the independent enforcement boundary of Gateway mode.
Authorization Gateway
The separately maintained Go Gateway independently validates identity and evaluates authorization.
- Verifying JWT identity claims.
- Resolving logical tools from trusted configuration.
- Enforcing exact-scope permissions.
- Recording authorization evidence.
- Dispatching authorized MCP operations.
Protected MCP Server
The MCP server exposes configured operational tools.
The Gateway constructs and dispatches authorized MCP tools/call requests to the configured destination.
AgentTrust implements a bounded, stateless HTTP JSON-RPC tool-execution adapter rather than a general-purpose MCP proxy or discovery service.
Architecture Overview
The primary execution flow is: AI Agent → Public AgentTrust Gateway Client → Authorization Gateway → Configured MCP Server.
The Gateway is the authoritative enforcement point for requests using this protected path.
Why Deployment Isolation Matters
An independent Gateway does not automatically make protected tools unreachable through other routes.
If an agent can directly communicate with the upstream MCP server, it may bypass Gateway authorization entirely.
AgentTrust’s demonstrated local Docker topology separates agent workloads from protected tools and permits access through the Gateway.
Other deployments require equivalent network or service-level restrictions to preserve this security boundary.
3. Agent Identity and Authentication
AgentTrust uses JWT-based identity verification in Gateway mode.
A separate trusted issuer signs the token using Ed25519, and the Gateway verifies the token using the corresponding public key.
What Does the Gateway Validate?
- EdDSA signature.
- Expected issuer and audience.
- Token expiration and issued-at time.
- Agent identity.
- Execution run identifier.
- Token identifier.
- Granted authorization scopes.
These checks establish the identity and authorization context presented to the Gateway.
However, token validity alone does not authorize a particular tool operation.
Short-Lived Execution Identities
The demonstration issuer generates JWTs with a 15-minute lifetime.
The SDK’s separate local mode defaults to five-minute HS256 tokens.
Short-lived credentials help reduce the exposure associated with compromised tokens.
The Gateway requires an expiration claim and rejects expired tokens, but it does not enforce a maximum token lifetime.
Managed token issuance, refresh, key rotation, JWKS discovery, and revocation are outside the current implementation.
These remain important considerations for broader deployments.
4. Fine-Grained Authorization for MCP Tools
One of AgentTrust’s key design decisions is to associate protected tool operations with explicitly configured permissions.
Consider the following implemented mappings:
| Logical Tool | Required Permission |
|---|---|
service_status | service.status |
restart_service | service.restart |
An agent granted service.status can request the configured health-check operation.
It cannot execute restart_service unless its credential includes service.restart.
Trusted Permission Resolution
The requesting agent supplies a logical tool identifier and JSON arguments.
The Gateway resolves the corresponding authorization requirement from trusted configuration.
The agent cannot redefine the permission required by a tool.
For example, it cannot claim that restart_service requires only service.status.
This prevents a less-trusted requester from controlling the authorization rules applied to its own requests.
Exact-Scope Matching
The Gateway evaluates explicitly required scopes against those granted to the authenticated identity.
Authorization uses exact-scope matching rather than wildcard or inherited permissions.
A valid token with insufficient scopes is denied.
Unknown or unconfigured tools are also rejected.
This establishes a deny-by-default authorization model for configured Gateway operations.
MCP Execution
Once authorization succeeds, the Gateway constructs an MCP tools/call request using its trusted tool mapping.
The requester does not choose the upstream MCP address, protocol method, or configured tool name.
This limits the ability of an agent to redirect authorized execution toward an unintended destination.
5. ALLOW, DENY, and Execution Evidence
A useful security architecture must demonstrate not only that authorization decisions are made, but also that those decisions control protected execution.
AgentTrust includes tests covering both authorized and unauthorized tool requests.
Scenario A: Authorized Service Status
An agent possesses the permission service.status and requests service_status.
- Validates the signed identity.
- Resolves the logical tool from trusted configuration.
- Confirms that the required scope is granted.
- Records the required pre-dispatch evidence.
- Constructs and dispatches the configured MCP
tools/call.
Scenario B: Unauthorized Service Restart
The same agent requests restart_service. However, its credential does not contain service.restart. The Gateway rejects the operation.
- The request is rejected with HTTP 403.
- The authorization decision is DENY.
- The execution outcome is NOT_EXECUTED.
- The protected MCP server receives zero calls.
The final assertion is particularly important.
The security control does not merely report an unauthorized operation. It prevents the protected operation from being invoked through the Gateway.
Authorization Versus Execution Outcome
| Authorization | Execution Outcome | Meaning |
|---|---|---|
| DENY | NOT_EXECUTED | Authorization prevented execution |
| ALLOW | SUCCEEDED | Authorized operation completed successfully |
| ALLOW | FAILED | Authorized operation failed |
| ALLOW | UNKNOWN | Execution outcome could not be determined |
An ALLOW decision does not guarantee successful downstream execution.
This distinction is especially important for operations that may produce side effects.
For example, if a Gateway loses connectivity after dispatching a restart operation, it may not be able to determine whether the operation completed.
Reporting the outcome as UNKNOWN is more accurate than assuming success or failure.
Audit Evidence and Failure Behavior
AgentTrust records authorization and execution lifecycle evidence using a local JSONL audit sink.
Required pre-dispatch audit failures block execution.
This ensures the Gateway does not intentionally proceed with a protected operation when mandatory pre-execution evidence cannot be recorded.
However, audit storage is not immutable or tamper-proof.
Additionally, an audit failure after an upstream handoff cannot undo a possible downstream side effect.
These distinctions are important when designing security systems that must operate correctly under partial failures.
6. Observability and Engineering Trade-offs
Authorization enforcement introduces another component into the execution path.
That component must be observable, understandable, and designed to handle failures safely.
OpenTelemetry Tracing
The Gateway emits OpenTelemetry spans covering important processing stages, including:
- Request handling.
- Authentication.
- Trusted tool resolution.
- Authorization.
- Audit writes.
- MCP execution.
When configured, these spans can be exported through OTLP to an external collector.
The Gateway also injects W3C trace context into outbound MCP requests.
The current implementation does not establish a complete distributed trace originating in the public SDK and continuing through the Gateway.
Its verified tracing capability is therefore Gateway instrumentation with downstream context propagation.
Prometheus-Compatible Metrics
The Gateway exposes Prometheus-compatible metrics for operational monitoring.
These include authorization activity and request-processing measurements.
Metrics help engineers investigate rejection patterns, latency, and operational behavior.
The implementation exposes a metrics endpoint; it does not provide a managed monitoring service.
Engineering Trade-offs
Independent Enforcement Versus Additional Latency
Placing authorization in the Gateway creates a stronger security boundary than relying solely on cooperative SDK checks.
However, it adds processing and network overhead to protected requests.
Exact-Scope Permissions Versus Policy Flexibility
Exact-scope matching makes authorization behavior predictable and easier to reason about.
More advanced authorization requirements, such as contextual policies or delegated permissions, would require additional capabilities.
Signed Credentials Versus Identity Lifecycle Management
Cryptographic verification establishes the authenticity of presented identity claims.
It does not eliminate the need for secure issuance, rotation, revocation, and credential distribution.
Auditability Versus Evidence Durability
Recording security decisions improves accountability and troubleshooting.
However, local audit files do not provide the durability, immutability, or operational guarantees of a dedicated enterprise audit platform.
These trade-offs demonstrate that effective security depends on both application-level controls and deployment architecture.
7. Engineering Lessons and Future Considerations
Building AgentTrust reinforced several architectural lessons.
Security Enforcement Must Be Independent of Agent Behavior
AI agents may dynamically select tools or respond to unexpected instructions.
Authorization cannot depend solely on the agent following intended behavior.
The Trust Boundary Must Be Explicit
A Gateway provides meaningful protection only when the surrounding deployment prevents direct access to protected systems.
Security architecture must account for network paths, service boundaries, and operational privileges.
Permission Requirements Must Come from Trusted Sources
The requesting agent should not determine the authorization rules applied to its own operations.
Trusted configuration establishes a clear separation between requested actions and security policy.
Execution Uncertainty Must Be Represented Accurately
An authorized operation can fail, time out, or complete without the Gateway receiving confirmation.
Separating authorization decisions from execution outcomes helps prevent misleading audit records.
Observability Supports Security Verification
Traces, metrics, and audit records provide different forms of evidence.
Together, they help engineers understand how requests were evaluated and what happened during execution.
Future Considerations
- Delegated authorization across multiple agents.
- Context-aware policy evaluation.
- Managed identity lifecycle.
- Stronger deployment and workload isolation.
- Centralized policy administration.
- More comprehensive distributed tracing.
- Durable security audit infrastructure.
These are areas for further engineering exploration rather than capabilities claimed by the current implementation.
Conclusion
As AI agents gain access to operational systems, security must extend beyond authenticating the requesting application.
Each protected action needs an independently evaluated authorization decision, backed by trusted permission requirements and enforced before execution.
AgentTrust demonstrates this approach through signed agent identities, exact-scope authorization, Gateway-controlled MCP dispatch, and observable execution evidence.
The implementation also highlights an essential architectural consideration: an authorization Gateway cannot provide a meaningful security boundary without deployment controls that prevent bypass.
That principle applies not only to MCP-based AI agents, but to any distributed system where less-trusted components initiate sensitive operations.
Explore AgentTrust
The AgentTrust project case study provides additional architecture details, implementation context, and supporting documentation.
Related evidence