Identity and Access Control

5.1 Agent Identity (Non-Human Identities)

Every agent in your system needs a real identity. Not a shared service account. Not an unnamed process running under a generic credential. A distinct, trackable identity.

For every agent, you should:

• Assign an agent_id and, ideally, a service identity (OIDC client, service account, or certificate)
• Store metadata that includes: owner team, business purpose, risk level and environment (dev/stage/prod), allowed tools and data domains, and guardrail profile (strictness level, domain-specific rules)
• Version agent definitions - prompts, tools, and policies - so you can roll back and reconstruct what happened during an incident

Never hardcode secrets in prompts or code. Use secrets managers everywhere. If a secret appears in a prompt, it is one injection away from being exfiltrated.

5.2 Authorization: RBAC + ABAC

A single access control model is not enough. Layer role-based and attribute-based controls together.

RBAC (Role-Based Access Control)

Define roles that map to what each agent actually does. A support_agent can read FAQ content and create tickets. A sales_analytics_agent can query sales dashboards. A devops_agent can read deployment status. Each role carries specific tool and data permissions - nothing more.

ABAC (Attribute-Based Access Control)

Layer contextual factors on top of roles:

• Tenant or organization (multi-tenant isolation)
• Data classification (public, internal, confidential, regulated)
• Environment (production vs. staging)
• Time of day
• User risk score
• Regulatory region (e.g., EU vs. MENA)

Where to Enforce

Enforce authorization in two places:

• Orchestrator - Determines which tools and data an agent may use for a given user and tenant
• Tool layer - Server-side double-check before any action executes

Do not rely on prompt instructions ("you may only access X") as your authorization mechanism. Prompts are suggestions to the model. They are not access controls. A determined adversary will get past them.

5.3 Just-in-Time Privilege

By default, agents run with low privilege. This is the baseline. When an agent needs to do something elevated, it requests temporary access - not a permanent upgrade.

For elevated actions, grant short-lived, scoped tokens tied to:

• The specific user who initiated the request
• The specific agent performing the action
• The tenant context
• The specific action or tool being invoked

Before granting elevated privileges, require one of:

• Explicit human approval (for high-risk operations)
• Policy-based approval from a risk engine (for medium-risk operations that need to move quickly)

Auto-expire elevated privileges when the task completes or after a short timeout. Log every elevation event - who requested it, what was granted, when it expired, and what happened while it was active.

5.4 Credential Handling and Multi-Tenancy

Credential management for agents follows the same principles as any production system, with a few AI-specific concerns:

• Use a centralized secrets manager - Vault, AWS Secrets Manager, Azure Key Vault, or equivalent. No exceptions.
• Rotate credentials regularly - Automate this. If rotation requires manual steps, it will not happen.
• Separate credentials per tenant - For SaaS-style agents, each tenant or organization gets its own credentials. Never use a "global" password or API key shared across tenants. One compromised tenant should not give access to another.
• Never expose secrets to the model or client - Keep credentials in backend-only code paths. The model should never see an API key, token, or password in its context window. If a secret reaches the model, assume it can be extracted.

5.5 Non-Human Identity Governance

Sections 5.1 through 5.4 cover the fundamentals of agent identity and access control. NHI governance is the discipline of managing these identities at enterprise scale - and it is where most organizations are falling behind.^[1]

Non-human identities already outnumber human identities in most enterprise environments by ratios measured in the dozens to one. Add agentic AI to the mix and that ratio accelerates. Traditional IAM was not designed for this scale or for the behavioral characteristics of agents that operate continuously, spawn sub-agents, and interact with dozens of tools and services per session.

Agent Identity Lifecycle

Every agent needs a unique named identity from provisioning to decommissioning. Shared credentials between agents are a control failure - when two agents share an identity, you cannot distinguish their actions in logs, and revoking one means disrupting both.

Shadow agents - deployed by teams without IT knowledge or IAM enrollment - are a specific risk pattern we flag on engagements. If an agent exists in your environment but not in your identity registry, you have a blind spot in your access control and audit posture.

Short-Lived, Task-Scoped Credentials

Agents should use short-lived tokens scoped to their specific task. When the task completes, the credential expires. Orphaned credentials from completed tasks are a persistent attack surface that grows over time. On engagements, we're finding agents provisioned with admin-level credentials because it was easier at setup time. That's a recurring pattern we flag.

Apply the Least Agency principle here: the credential should grant exactly the access needed for that task, nothing more, and expire the moment the task is done.

The Attribution Gap

When agents inherit human credentials or delegate to sub-agents without proper scoping, individual actions become untraceable. A human user authorizes an agent to act on their behalf. That agent spawns a sub-agent. The sub-agent calls an MCP tool. Whose identity is on that tool call? If the answer is "the original human's," you have an attribution gap that makes incident investigation nearly impossible.

Every delegation step needs its own scoped credential with a traceable chain back to the originating identity.

NHI-Specific Behavioral Baselines

Traditional user behavior analytics (UBA) tools are calibrated for human patterns - login times, geographic locations, typing speeds. Machine identities behave differently. An agent that makes 500 API calls in a minute is normal. An agent that suddenly starts calling a tool it has never used before is anomalous. Build behavioral baselines that account for machine identity patterns, not human ones.^[2]

References

1. OWASP Top 10 for Agentic Applications 2026 - ASI03: Identity and Privilege Abuse. OWASP GenAI Security Project. owasp.org
2. Securing Agentic AI: A Threat Model and Call to Action for the Model Context Protocol. CoSAI / OASIS Open, January 2026. Agent identity sections. cosai.oasis-open.org