Secure AI agents in production: identity management, granular access control, secrets management. 2026 best practices with Claude and MCP.
The first AI assistants deployed in enterprises had a relatively passive role. They answered questions, summarized documents, or generated content. Their impact stopped at information production.
Agentic architectures completely change this logic.
Today, an agent can open a Jira ticket, modify a CRM, launch a CI/CD workflow, send an email, trigger a Stripe refund, or chain multiple API calls autonomously.
From the moment an agent acts on real systems, one question becomes unavoidable:
Who is actually acting?
This is not a question about model provider, framework, or protocol. It's an architectural question.
A new category of identity
For years, security architectures have relied on two categories of identity:
- human users;
- technical identities (applications, services, microservices).
AI agents don't fully belong to either of these categories.
They reason, choose tools, adapt their actions to context, and sometimes execute dozens of operations in succession.
They constitute a new category of identity that we'll call agentic identity in this article.
Definition
An agentic identity is the set of information allowing you to identify an agent, determine on whose behalf it acts, know the limits of its autonomy, and reconstruct each of its decisions.
This definition will guide us through the REST of the article.
An API key is not an identity
Early agent implementations often follow this architecture.
Application
│
▼
LLM API Key
│
▼
AI Agent
This representation is convenient.
It is also misleading.
The API key identifies your application to the model provider.
It doesn't identify the agent acting in your information system.
Two agents can share the same API key while having completely different responsibilities.
The agent's identity therefore belongs to your architecture, not to the model provider.
The model never directly performs an action
You often hear:
"Claude deleted an order."
or
"GPT created a refund."
In reality, a language model only makes a proposal.
Your infrastructure then decides:
- whether this action is allowed;
- with what permissions;
- for which user;
- on which resources.
User
│
▼
Application
│
▼
Agent Runtime
│
proposes an action
▼
Policy Engine
│
▼
Business Tool
│
▼
Target System
This separation between reasoning and execution is one of the fundamental principles of modern agentic architectures.
The real question is responsibility
An enterprise must be able to answer, weeks after an incident:
- Which agent acted?
- On behalf of which user?
- In which tenant?
- Which policy authorized this operation?
- Which tool was invoked?
A log stating only:
"The model called updateCustomer()"
provides almost no value.
A modern architecture must enable you to reconstruct the entire decision chain.
An identity is always contextual
The same agent can intervene:
- for multiple users;
- in multiple organizations;
- in multiple environments;
- with different permissions depending on the task.
Its identity therefore never boils down to a simple identifier.
Agent
├ identity
├ represented user
├ tenant
├ environment
├ session
└ temporary permissions
Context is an integral part of identity.
Historical architectures don't address this issue
OAuth, OpenID Connect, Kubernetes Service Accounts, or workload identities mainly answer one question:
Which component is requesting access to a resource?
AI agents add an additional dimension:
Why is this action being performed, on whose behalf, and within what limits?
This difference justifies a new layer of governance.
Before talking about JWT or rbac
Most articles immediately jump to technologies:
- JWT;
- OAuth;
- RBAC;
- Vault;
- secret rotation.
All are important.
But they come too early.
Before choosing a technology, you must define what an agent's identity is and what information it should carry.
That's precisely the goal of the next chapter, which introduces an Agent Identity Reference Model independent of vendors, frameworks, and language models.
Key Takeaway
Models will evolve.
Frameworks will change.
Protocols will appear and disappear.
However, every agentic architecture will always need to answer the same question:
Who is actually acting, on whose behalf, with what permissions, and under what control?
Definition
An Agent Identity Reference Model is a conceptual model describing the minimum information a platform must know to identify an agent, determine on whose behalf it acts, decide what actions it can perform, and ensure complete traceability of its activity.
Once you consider an agent as a true software identity, another question immediately emerges:
What information does a platform actually need to authorize an agent to act?
Most implementations answer with a list of technical mechanisms: a JWT, an API key, some permissions, and maybe an RBAC role.
In reality, these mechanisms only express part of identity. For an agent to act safely, you must answer several independent questions.
Overview
| Layer | Question | Example Technologies |
|---|---|---|
| Identity | Who is this agent? | UUID, SPIFFE ID |
| Authentication | Can it prove its identity? | JWT, OAuth 2.0, mTLS |
| Delegation | On whose behalf is it acting? | OAuth, OIDC |
| Authorization | What can it do? | RBAC, ABAC, Cedar, OPA |
| Secrets | How does it access resources? | Vault, AWS Secrets Manager |
| Observability | Can we explain each decision? | OpenTelemetry |
| Revocation | Can we stop it immediately? | Token revocation |
Layers are independent
A common mistake is to mix multiple responsibilities.
A JWT doesn't decide permissions. A policy engine doesn't prove identity. A secrets manager doesn't authorize any action.
Each layer answers a single responsibility. This separation allows you to replace one technology without questioning the overall architecture.
Model schema
Identity
│
┌─────────────────┴─────────────────┐
│ │
Authentication Delegation
│ │
└─────────────────┬─────────────────┘
▼
Authorization
│
┌────────────────┴────────────────┐
│ │
Secret Access Observability
│ │
└────────────────┬────────────────┘
▼
Revocation
Identity is not authentication
These two notions are often confused.
Identity describes who the agent is.
Authentication verifies that it is indeed who it claims to be.
Being authenticated never means being authorized.
The six layers
1. Identity
Each agent has a stable identifier, a version, an owner, and an execution environment.
agent:
id: support-agent
version: 2.3.1
owner: customer-support
environment: production
2. Authentication
Authentication proves this identity through a JWT, OAuth, mTLS, or workload identity.
3. Delegation
An agent rarely acts on its own behalf. It acts for a user, tenant, or business process.
4. Authorization
Modern permissions increasingly rely on policy engines.
The main models are:
- RBAC
- ABAC
- PBAC
- ReBAC
Agentic architectures generally favor PBAC, which can evaluate execution context.
Node.js example:
const decision = await policyEngine.evaluate({
identity,
tool: "refundOrder",
amount: 75,
tenant: "acme",
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
await refundOrder();
5. Secrets
The model never directly handles secrets.
It expresses an intent; the application retrieves secrets from a dedicated manager.
6. Observability
Each decision must be traceable: identity, represented user, applied policy, result, and execution duration.
7. Revocation
Every identity must be immediately disableable to prevent any new action.
Key takeaway
Models change.
Frameworks evolve.
Protocols appear and disappear.
However, an architecture will always need to answer the same questions:
- Who is acting?
- On whose behalf?
- What can they do?
- How do we protect resources?
- How do we explain decisions?
- How do we stop this agent immediately?
As long as these questions have answers, your architecture will remain valid regardless of the model provider or framework used.
The Agent Identity Reference Model presented in the previous chapter is intentionally technology-agnostic.
It answers an architectural question:
What information must we handle to secure an agent?
This chapter answers another question:
How do we concretely implement this model in a modern application?
The good news is that you don't need to invent a new security stack. Most enterprises already have the necessary building blocks.
Reference architecture
User
│
▼
Identity Provider
│
▼
Business Application
│
▼
Agent Runtime
┌───────────────┼────────────────┐
▼ ▼ ▼
Policy Engine Secret Manager Observability
│
▼
Tool Gateway
│
┌────┼───────────────┐
▼ ▼ ▼
CRM PostgreSQL Stripe
The language model is intentionally not at the center of the diagram.
It produces proposals.
The runtime applies security policies.
The runtime becomes the control point
Every tool call must be treated as a security decision.
Before executing an action, the runtime must answer several questions:
- Who is the agent?
- Which user is it acting for?
- Which tenant is involved?
- Is this action authorized?
- Are security limits respected?
In other words, the runtime becomes a Policy Enforcement Point (PEP).
A node.js middleware rather than scattered logic
A good practice is to centralize controls.
export async function authorizeTool(ctx, toolName) {
const decision = await policyEngine.evaluate({
identity: ctx.identity,
tool: toolName,
tenant: ctx.tenant,
delegatedUser: ctx.user.id
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
return decision;
}
Then each tool uses this middleware.
server.registerTool({
name: "refundOrder",
async execute(args, ctx) {
await authorizeTool(ctx, "refundOrder");
return refundService.execute(args);
}
});
This way, security rules remain independent from the model and prompt.
A JWT transports identity, it decides nothing
A JWT can contain useful information:
{
"agent":"support-agent",
"tenant":"acme",
"delegatedUser":"user-482",
"scope":["orders.read","orders.update"]
}
But a JWT never answers the question:
Is this operation authorized right now?
This decision always belongs to the policy engine.
Permissions are evaluated with every action
In an agentic architecture, permissions aren't fixed at login time.
Each tool call is a new decision.
For example, a refund might depend on:
- the amount;
- the tenant;
- the role of the represented user;
- the environment;
- the risk policy.
The runtime must therefore query a policy engine before each sensitive operation.
Tools represent business capabilities
Avoid exposing raw technical primitives.
Don't do this:
executeSQL()
executeShell()
deleteCustomer()
Prefer tools expressing business intent.
findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()
This approach significantly reduces the attack surface and simplifies authorization policies.
Secrets never leave the infrastructure
The model should never receive a Stripe key, PostgreSQL password, or AWS token.
The runtime retrieves these secrets from a dedicated manager.
import Stripe from "stripe";
const stripe = new Stripe(
await secretManager.get("stripe-API-key")
);
The model expresses an intent.
The application makes the technical call.
MCP doesn't replace controls
The Model Context Protocol (MCP) standardizes tool discovery and invocation.
It never decides whether a tool can be used.
Even if a MCP server exposes:
deleteAllCustomers()
the final decision always belongs to:
- the runtime;
- the policy engine;
- your architecture.
MCP describes capabilities.
Your platform decides which ones are actually accessible.
Build or buy?
Not all teams have the same needs.
| Project Size | Recommendation |
|---|---|
| Prototype | Rules coded in runtime |
| Few agents | Simple RBAC |
| Multi-tenant | Policy Engine |
| Regulated organization | Cedar, OPA, or equivalent solution |
The shift to a policy engine is justified when rules become numerous, evolving, or shared across multiple agents.
A durable architecture
One of the main benefits of this approach is vendor independence.
You can replace:
- Claude with GPT;
- GPT with Gemini;
- LangGraph with CrewAI;
- MCP with another protocol.
The security architecture stays the same.
Your runtime, policies, secrets, and audit logs belong to your information system.
They constitute the true trust layer of your platform.
Key Takeaway
The language model is never the security authority.
It proposes actions.
Your infrastructure decides if they can be executed.
At this point, a modern architecture has:
- an identity for each agent;
- an authentication mechanism;
- a policy engine;
- centralized secrets management.
These components are necessary, but not sufficient.
An architecture is truly secure only if it can be audited, explained, and stopped at any time.
Audit is no longer just a log file
In an agentic system, it's no longer enough to record that an endpoint was called.
Every important decision should produce an event tracing:
- the agent's identity;
- the represented user;
- the tenant;
- the requested tool;
- the applied policy;
- the decision (ALLOW or DENY);
- the execution result.
Example:
{
"timestamp": "2026-07-17T10:48:31Z",
"agent": "support-agent",
"delegatedUser": "user-482",
"tenant": "acme",
"tool": "refundOrder",
"decision": "ALLOW",
"policy": "refund-policy-v3",
"durationMs": 91
}
These events allow you to reconstruct a decision weeks after execution.
The most frequent anti-patterns
1. A shared API key
All agents use the same identity.
Consequence: impossible to know which one is responsible.
2. Secrets transmitted to the model
A Stripe key or SQL password should never appear in the context sent to the LLM.
3. Permissions defined in the prompt
A prompt is not a security mechanism.
Authorization rules must be implemented on the infrastructure side.
4. Tools that are too generic
Avoid:
executeSQL()
executeShell()
Prefer:
createInvoice()
updateShippingAddress()
Tools should represent business intents.
An audit checklist
Before going to production, verify notably:
- Does each agent have a unique identity?
- Are represented users identified?
- Are permissions evaluated before each tool call?
- Are secrets stored in a Secret Manager?
- Is each decision logged?
- Can an agent be revoked immediately?
- Do tools expose business capabilities rather than technical primitives?
If any answer is no, the architecture probably deserves review.
Zero trust applied to agents
Zero Trust principles remain perfectly suited for agentic architectures.
Every request must be:
- authenticated;
- authorized;
- traced;
- limited to what's necessary.
No agent should be considered implicitly trustworthy.
Frequently asked questions
Should there be one JWT per agent?
Not necessarily.
What matters is that each execution has an authenticatable and contextualized identity.
Is rbac sufficient?
For a prototype, often yes.
For multiple agents, multiple tenants, or dynamic rules, a policy engine quickly becomes preferable.
Does MCP secure tools?
No.
MCP describes available tools.
Access controls remain your platform's responsibility.
Should the model know secrets?
Never.
The model formulates an intent.
The runtime makes technical calls with its own identities.
Conclusion
For a long time, application security has been organized around users and services.
Agentic architectures introduce a third category of identity: the autonomous agent.
This evolution requires rethinking several foundations:
- identity;
- delegation;
- authorization;
- secrets management;
- observability;
- revocation.
Technologies will continue to evolve.
Language models will be replaced.
Frameworks will change.
However, the fundamental questions will remain the same:
- Who is acting?
- On whose behalf?
- With what permissions?
- How do we explain each decision?
- How do we immediately stop an agent?
Organizations capable of answering these questions will have a durable architecture, independent of model providers and robust enough to evolve their agentic systems over time.
