B5: Identity and Least Privilege for AI AgentsAI agents have different identity characteristics from humans and stable services: short-lived and task-scoped, executing delegated actions on behalf of users, potentially spawning child agents, performing high-volume API activity at machine speed. Traditional IAM forces agents into shared service accounts losing precise identity at workload instance level and constrained capability at operation level. Least privilege for agents: each agent instance holds only permissions needed for the specific current task, credentials expire when task completes. Credential scoping: tokens carry resource target, allowed scopes, optional constraints like transaction limits, and expiry time. Session containment and blast radius: short-lived scoped tokens mean compromise gives attacker one bounded operation for limited time rather than broad indefinite access. AgentID from Mirror Security applies zero-trust through two-plane architecture: Identity Broker handles identity verification, policy evaluation, token issuance, introspection, revocation, audit; Resource Gateway handles runtime validation, policy checks at request time, rate limiting, connector enforcement. Four zero-trust foundations: short-lived tokens expiring minutes/hours, capability-scoped authorization with resource target and scopes, workload and delegation context identifying agent instance and delegated principal, continuous runtime enforcement at request time. Worked example: customer support agent refund with AgentID requests payments:refund capability token for specific customer constrained to original transaction value, Broker mints 5-minute token after policy check, Gateway validates at request, token expires after use. Without AgentID: shared credential can modify any billing record indefinitely. AgentID vs cloud workload identity: cloud answers which service is calling not which agent instance under which delegated user with scoped capability. AgentID sits above attestation layer consuming SPIFFE or cloud tokens then layering capability scoping, policy evaluation, delegation context, runtime enforcement. AgentIQ DSL identity patterns: allow message where role == admin, conditional policies if environment == production, check_model instruction_adherence and safety_boundary, check_tokens count with limit for rate controls. Five anti-patterns: shared service accounts, hardcoded API keys, over-permissioned roles, no revocation path, no audit trail. Adoption path: capability tokens, gateway enforcement, federated identity, spawn-time lifecycle, connector constraints.PT26MIntermediatetrueen2026-04-05Mirror Academy
Module B5 of 6 · Track 2B: AI Agent Security
Zero Trust for autonomous agents
Identity & Least Privilege
Every tool an agent calls, it calls under some credential. Most deployments today use one shared credential for all agents. This module explains why that creates an unacceptable blast radius and how to fix it with task-scoped tokens and zero-trust identity.
Why agent identity is different from user identity
Traditional identity and access management was designed for two principal types: humans who authenticate once and hold a session, and stable services that hold long-lived credentials and make predictable calls. Both types have consistent, auditable access patterns that IAM tools were built to reason about.
AI agents fit neither model. They have four characteristics that break traditional IAM assumptions.
Human or stable service
Authenticates once, holds a persistent session
Acts under its own authority and identity
Single instance (one user, one service)
Predictable, low-frequency API patterns
IAM tools work well for this model
AI agent
Short-lived and task-scoped: exists only for the duration of a task
Delegated authority: acts on behalf of a user or workflow it may never directly communicate with
Many instances: dozens or thousands of identical agent instances running simultaneously
High-volume, fast: hundreds of API calls per session at machine speed
Traditional IAM breaks for this model
When these agent workloads are forced into a shared service account model, you lose two core security properties that IAM exists to provide: precise identity at the workload instance level (you know the service is calling but not which agent instance, acting under which delegated user) and constrained capability at the operation level (the shared credential has broad permissions rather than task-specific scopes).
This is not a future problem. From the Mirror Security blog on AgentID: "AI agents are now operating across payment systems, ticketing systems, internal data stores, and SaaS control planes. But in too many environments, access control still relies on shared long-lived secrets designed for static services. The result is broad access where narrow access is needed, weak attribution when incidents happen, slow revocation during active response, and difficult compliance evidence for delegated machine actions."
Section 02
How agents authenticate to tools and services today
Most production agent deployments today use one of three credential patterns. Each has a different security profile. Understanding which pattern your deployment uses is the starting point for improving it.
Static API Key
Shared static API key
One API key configured in the agent's environment. All agent instances, all tasks, all users share it. Key is long-lived (months or years). Rotation is manual and disruptive. No distinction between agent instances in audit logs.
Risk: one key compromised means all agent access is compromised. No workload-level attribution. No automatic expiry.
Service Account
Shared service account (OAuth or cloud IAM role)
A service account with a broad role (for example, database read/write, payments API full access). All agents assume this role. Slightly better than a static key because sessions can be shorter, but still no per-task or per-instance scoping. Compromising any agent session gives access to everything the role permits.
Risk: blast radius equals everything the role can access. Over-permissioned by design because one role serves all tasks.
Scoped Token
Task-scoped capability token (target model)
A short-lived token issued specifically for the current task. Carries explicit resource target, allowed operations, optional constraints, and an expiry time. Unique per agent instance and task. Full delegation lineage in audit logs: which agent instance, which delegated principal, which task, which policy authorised it.
Blast radius: one bounded operation for one record, expiring in minutes. This is what AgentID provides.
Most deployments today use the first two patterns. The transition from static keys and service accounts to scoped tokens does not require replacing your entire application stack. AgentID is designed to sit above existing identity infrastructure and layer on the scoping and governance that agents require without replacing cloud IAM or SPIFFE deployments already in place.
Section 03
Least privilege for agents
Least privilege is a standard security principle: give each entity only the permissions it needs, and nothing more. For human users and stable services, this is typically applied at the role level: a developer gets developer permissions, a read-only reporting service gets read access.
For agents, least privilege needs to be applied at a much finer grain: the individual task level. An agent performing task A this minute should hold credentials for task A only, not for tasks B through Z that it might theoretically need later. When task A is complete, those credentials should expire.
Four foundations of zero-trust least privilege for agents (from Mirror Security AgentID)
Foundation 1
Short-lived access tokens
Credentials expire by default. Tokens that last minutes or hours dramatically reduce exposure compared to static secrets that persist for months or years.
Token expires: 5 minutes after issue. Cannot be reused after expiry.
Foundation 2
Capability-scoped authorization
Tokens carry explicit capabilities: resource target, allowed scopes, optional constraints (such as transaction limits), expiry, and identity context. Not a broad role grant.
Token grants: payments:refund for customer #4521, max amount $299. Nothing else.
Foundation 3
Workload and delegation context
Security and audit teams can answer three questions: which agent instance performed the action, under which delegated principal, and under which tenant and policy context.
Authorization is not a one-time check at token issuance. Enforcement happens at request time with runtime context, rate controls, and connector-level validation on every call.
Gateway checks token validity, scope, and constraints on every API call, not just at login.
Least privilege is the structural defence that all other B-path controls depend on. B2 (prompt injection), B3 (tool call policies), and B4 (guardrails) are detection and enforcement layers. If every layer fails and the agent follows a malicious instruction, least privilege determines how much damage can be done. An agent with a five-minute scoped token for one operation limits the impact to that one operation. An agent with a shared service account credential limits the impact to nothing: the attacker has everything.
Section 04
Credential scoping
A scoped credential is not just a short API key. It is a structured document that states exactly what the holder is allowed to do, for how long, and under whose authority. The structure of the token is what enables enforcement at runtime.
Anatomy of a capability token
resource_target"payments-api/customers/4521" — exactly which system and record
allowed_scopes["payments:refund"] — only this operation is permitted, not read/write/delete
constraints{"max_amount": 299.00, "currency": "USD"} — optional limits on the operation
expires_at"2026-04-05T14:32:00Z" — 5 minutes from issue. Token cannot be used after this.
agent_instance_id"agent-7f3a-c291" — which specific instance holds this token
delegated_principal"[email protected]" — the user whose authority the agent is acting under
policy_version"refund-policy-v2" — which policy evaluation authorised this token
Every field in the token carries enforcement meaning. The Resource Gateway validates each field at request time: does the target match, does the scope match, do the constraints hold, is the token still valid? A token that passes all fields can proceed. A token that fails any field is rejected at the gateway before the downstream API is ever called.
# Pattern: request a scoped token before each task# Each token carries only what the task needs# --- Task: issue a refund ---refund_token = agentid_broker.request_capability_token(
agent_instance_id="agent-7f3a-c291",
delegated_principal="[email protected]",
resource_target="payments-api/customers/4521",
scopes=["payments:refund"],
constraints={"max_amount": 299.00, "currency": "USD"},
ttl_seconds=300# 5 minutes
)
# Token is used once, then discardedresult = payments_gateway.refund(
token=refund_token,
customer_id="4521",
amount=149.00
)
# After the refund, the token cannot be reused# Attacker who intercepts this token can only issue# one refund of max $299 for one customer, for 5 minutes# --- Different task: read a ticket ---# Completely separate token, different scopeticket_token = agentid_broker.request_capability_token(
agent_instance_id="agent-7f3a-c291",
delegated_principal="[email protected]",
resource_target="ticketing-api/tickets/TKT-9901",
scopes=["tickets:read"],
ttl_seconds=60
)
# Compromising the refund token gives no access to tickets# Compromising the ticket token gives no access to payments
Section 05
Session containment and blast radius
Session containment means structuring your agent credentials so that when a session is compromised, the damage is bounded. Blast radius is the maximum damage a successful attack can cause from one compromised credential.
The goal is not to prevent compromise. It is to make compromise survivable by limiting what an attacker can do with a stolen credential.
Shared service account credential
Shared Cred
All customer records (read/write)
All transactions (read/create/void)
All subscriptions (modify/cancel)
All billing details (update)
Attacker holds all of this, indefinitely
AgentID scoped capability token
Scoped Token
payments:refund for customer #4521
Max $299.00 constraint
Expires in 5 minutes
Attacker holds this only, for 5 minutes
The blast radius reduction is not marginal. From the Mirror Security blog: "If the agent runtime is compromised during that window, the attacker holds a token that can only issue one bounded refund for one customer, expiring in minutes. Compare that with a shared credential that can modify any billing record indefinitely."
This is why session containment is described as a structural control in B2's defence-in-depth stack: it works regardless of whether detection layers catch the attack. Even if every other guardrail fails, a scoped short-lived token limits the attacker to one bounded action.
Section 06
AgentID: zero-trust identity for agents
AgentID is Mirror Security's identity and access platform for autonomous agents. It applies zero-trust principles through a two-plane architecture, separating the concerns of identity verification and token issuance from runtime enforcement.
How AgentID compares to existing identity infrastructure
Cloud Workload
Answers: which service is calling? Does not answer: which agent instance, acting under which delegated user, with which scoped capability, under which tenant policy.
AgentID position: consumes cloud workload tokens as identity inputs, then layers capability scoping and governance on top.
SPIFFE SPIRE
Provides a verifiable cryptographic identity document for a workload. Does not mint capability-scoped tokens with runtime constraints, enforce per-operation policies, or maintain delegation lineage across agent hierarchies.
AgentID position: can consume SPIFFE IDs as identity inputs. Adds the authorization layer that SPIFFE does not provide.
AgentID does not replace your existing infrastructure. It is designed to complement cloud workload identity and SPIFFE deployments already in place. It sits above the attestation layer, consuming existing identity proofs as inputs and adding the capability scoping, delegation context, and runtime enforcement that agent workloads require but that attestation alone does not provide.
Section 07
Policy-based identity controls with AgentIQ
AgentID controls which resources the agent can access at the infrastructure level. AgentIQ controls what the agent can say and do within those resources at the model level. The two products work at different layers and complement each other.
Several patterns in the AgentIQ Policy DSL are directly relevant to identity and access: role-based access rules, environment-conditional policies, model behaviour checks, and rate controls.
@version "1.0.0";# Pattern 1: Role-based access# Allow elevated actions only to users with the right rolepolicy role_based_access {
deny message wheretrue; # deny all by default
allow message where role == "admin"; # allow admin
allow message where role == "analyst"; # allow analyst
}
# Pattern 2: Environment-conditional policies# Apply stricter controls in production than in developmentif environment == "production"then {
policy strict_mode {
deny message input wherecheck_prompt_injection() == true;
deny message input wheredetect_jailbreak() == true;
check_output hallucination with { threshold: 0.85 };
check_output pii;
}
} else {
policy dev_mode {
allow message wheretrue; # relaxed for development and testing
}
}
# Pattern 3: Model identity adherence checks# Enforce that the model behaves within its assigned rolepolicy model_identity {
check_model instruction_adherence; # model follows its system instructions
check_model safety_boundary; # model stays within safety boundaries
check_model personality_drift; # model has not been manipulated into a different persona
}
# Pattern 4: Rate controls (prevent token/session abuse)policy rate_controls {
check_tokens count with { limit: 4096 }; # block context window stuffing
check_tokens entropy; # detect unusual token patterns
}
# Pattern 5: Combined identity and access chain
chain agent_identity_controls {
policy access_layer {
deny message wheretrue;
allow message where role == "support_agent";
allow message where role == "admin";
}
policy behaviour_layer {
check_model instruction_adherence;
check_model safety_boundary;
}
policy rate_layer {
check_tokens count with { limit: 4096 };
}
}
check_model vs check_output.check_model instruction_adherence verifies that the model is following its assigned role and system instructions, detecting if the model has drifted from its intended identity through prompt manipulation. check_model safety_boundary detects boundary violations. These are different from check_output statements (B4) which check the content of model responses. Model identity checks verify the model is being the agent it is supposed to be, not just saying appropriate things.
Section 08
Common anti-patterns and fixes
Five identity anti-patterns appear in almost every agent deployment audit. Each one has a specific blast radius consequence and a specific control that addresses it.
Shared service account
Critical
Anti-pattern
One service account credential shared by all agent instances and all tasks. No workload-level identity. All agents look identical in audit logs. One credential for everything.
Fix
Issue per-instance credentials or short-lived task-scoped capability tokens. Each agent instance and task gets a unique identity. Compromise affects one session, not all.
Hardcoded API keys
Critical
Anti-pattern
API keys embedded directly in code, Docker images, or environment variables. Never rotated because rotation is disruptive. Often accidentally committed to source control.
Fix
Dynamic credential issuance with automatic expiry. Use a secrets manager for base credentials, then issue task-scoped tokens from those for each agent operation. Keys are never in code.
Over-permissioned roles
High
Anti-pattern
Agent has database admin role when it only needs to read one table. Agent has payments:full-access when it only ever issues refunds. Broad roles because scoping is inconvenient.
Fix
Task-scoped credentials with explicit resource target and operation limits. Start from zero permissions and add exactly what each task needs. Review roles every time a new task type is added.
No revocation path
High
Anti-pattern
When an agent is compromised, there is no fast way to cut off its access. Revoking a static API key requires finding all places it is used. The attacker has minutes or hours before revocation takes effect.
Fix
Short-lived tokens expire automatically. For longer operations, centralized revocation through AgentID propagates immediately to the Gateway. Revocation does not require finding and rotating embedded credentials.
No audit trail
Medium
Anti-pattern
Audit logs show the service account made an API call but nothing else. Which agent instance? Under which user's delegated authority? Pursuant to which task? Impossible to answer during incident response.
Fix
Every capability token carries identity context that appears in downstream audit logs: agent instance ID, delegated principal, tenant, and policy version. Full delegation lineage is available for every action, automatically.
Section 09
Production identity checklist and adoption path
Before deploying agents with access to production systems, verify the following identity controls. The adoption path below the checklist is the recommended sequence for teams currently using shared credentials who want to move toward zero-trust agent identity.
Replace static credentials with short-lived scoped tokens for each agent task. Implement the broker and establish the token structure with resource targets and scopes. Immediate blast radius reduction.
Immediate impact: blast radius drops from full service to one task
2
Runtime enforcement through the gateway
Move authorization checks from issuance time to request time. The gateway validates every downstream call, not just the initial token grant. Adds constraint enforcement and rate controls.
Federated identity for delegated enterprise principals
Connect to existing identity providers so that delegation lineage traces back to real enterprise users. Agent actions become attributable to the user who initiated them, not just the agent service.
Adds: user-level attribution, delegated principal context in audit logs
4
Spawn-time agent lifecycle and delegation lineage
Control how child agents inherit (or do not inherit) permissions from parent agents. Each agent in a hierarchy has its own scoped identity. Prevents privilege escalation through agent spawning.
Add per-connector constraints for payments, data modification, record deletion, and other high-risk operations. Constraints are enforced at the gateway before the downstream system is called.