We need machine identity and permissions for thousands of AI agents. What agent security stack should we consider?

For thousands of AI agents, I’d avoid buying a single “AI agent security” product. The durable architecture is a machine-identity + authorization + secrets + runtime-policy stack, with the model itself never being the security boundary.

Current guidance from Microsoft and AWS is converging on distinct agent/workload identities, short-lived credentials, least privilege, delegated user context, deterministic policy checks before tool calls, and auditable attribution.

The stack I’d evaluate

The particularly important distinction is authentication vs. authorization. Knowing that “Agent 7 is Agent 7” doesn't tell you whether Agent 7 should delete this customer's database record right now. Modern agent IAM discussions increasingly emphasize this gap.

My shortlist

1. SPIFFE/SPIRE + Cedar/OpenFGA — best infrastructure-centric foundation

If you're building a platform for thousands of heterogeneous agents, I'd seriously consider making SPIFFE/SPIRE the machine-identity substrate. Agents/workloads get identities independent of where they're running, and your authorization system consumes those identities.

Then put Cedar or OpenFGA above it for fine-grained authorization.

This gives you a relatively vendor-neutral architecture:

Agent → SPIFFE identity → Policy engine → Tool/API → Resource

rather than tying agent identity to one cloud or LLM provider.

2. Aembit — strongest “buy rather than build” candidate for workload access

Aembit is explicitly extending workload IAM to AI agents, including SPIFFE compatibility, credential issuance, attestation and policy enforcement. Its agent model can combine the human identity + the agent identity when making an access decision.

That blended identity model is especially interesting for enterprise copilots:

Alice → Sales Agent → Salesforce

rather than simply:

Sales Agent → Salesforce

The former lets you answer both “which agent?” and “on whose authority?”

3. Microsoft Entra Agent ID — compelling if you're already Microsoft-heavy

Microsoft now has a purpose-built agent identity layer with agent blueprints/identities, lifecycle governance, Conditional Access, Identity Protection and auditing.

If your estate is heavily Entra + Azure + Microsoft 365, I'd put this near the top of the evaluation rather than introducing another identity plane.

4. AWS-native stack — compelling for an AWS estate

AWS's current agentic-AI guidance explicitly calls for distinct agent identities, short-lived credentials, permission boundaries, user-context propagation and continuous permission validation.

If you're predominantly AWS, I'd evaluate the native IAM/AgentCore direction before introducing another workload-identity vendor.

5. Pomerium / agent gateway approach — interesting at the enforcement point

Pomerium is positioning around runtime access enforcement for agents/MCP, while other vendors focus more on discovering and governing the non-human identities themselves. That's an important architectural distinction.

For thousands of agents, I'd want a gateway/policy enforcement point even if identity comes from another system.

The architecture I'd actually build

I'd aim for something like:

                    Human / Event / Schedule
                              │
                              ▼
                       ┌─────────────┐
                       │ Agent       │
                       │ Identity    │
                       └──────┬──────┘
                              │
                    short-lived identity
                              │
                              ▼
                    ┌──────────────────┐
                    │ Authorization    │
                    │ Policy Engine    │
                    │                  │
                    │ user + agent +   │
                    │ task + tool +    │
                    │ resource + risk  │
                    └────────┬─────────┘
                             │
                    allow / deny / step-up
                             │
                             ▼
                    ┌──────────────────┐
                    │ Tool/API Gateway │
                    │ MCP / REST / DB  │
                    └────────┬─────────┘
                             │
                             ▼
                       Enterprise data

And every important request should produce an immutable-ish audit chain:

human → agent → delegated authority → policy decision → tool → resource → result

That attribution becomes extremely important once agents operate autonomously. AWS specifically recommends keeping agent and human permissions distinct rather than allowing an agent to assume a human identity.

One design principle I'd make non-negotiable

Don't give an agent a permanent “Salesforce Admin” credential.

Instead:

Agent requests Salesforce:update-opportunity for tenant X, opportunity Y, initiated by user Z, for task T. The authorization layer decides whether that specific action is permitted and, ideally, issues a short-lived credential/token scoped to it.

This is much closer to capability-based / policy-based access than traditional RBAC. The Cloud Security Alliance's recent guidance similarly argues that ABAC/PBAC are better suited to dynamic, task-specific agent access than static roles alone.

If I were narrowing this to a 5-vendor bake-off

I'd start with:

• SPIFFE/SPIRE — open workload identity baseline
• Aembit — workload/agent access control
• Microsoft Entra Agent ID — enterprise IAM/governance
• AWS AgentCore Identity/IAM — AWS-native alternative
• Pomerium — runtime gateway/enforcement model

Then separately evaluate Cedar vs. OpenFGA for the authorization layer.

The key procurement question isn't “Which vendor secures AI agents?” It's “Which system owns the authoritative identity, which system makes the per-action authorization decision, and where can we revoke an agent in seconds?” If a product can't answer all three cleanly, I wouldn't make it the foundation for thousands of agents.

My shortlist

1. SPIFFE/SPIRE + Cedar/OpenFGA — best infrastructure-centric foundation

If you're building a platform for thousands of heterogeneous agents, I'd seriously consider making SPIFFE/SPIRE the machine-identity substrate. Agents/workloads get identities independent of where they're running, and your authorization system consumes those identities.

Then put Cedar or OpenFGA above it for fine-grained authorization.

This gives you a relatively vendor-neutral architecture:

Agent → SPIFFE identity → Policy engine → Tool/API → Resource

rather than tying agent identity to one cloud or LLM provider.

2. Aembit — strongest “buy rather than build” candidate for workload access

Aembit is explicitly extending workload IAM to AI agents, including SPIFFE compatibility, credential issuance, attestation and policy enforcement. Its agent model can combine the human identity + the agent identity when making an access decision.

That blended identity model is especially interesting for enterprise copilots:

Alice → Sales Agent → Salesforce

rather than simply:

Sales Agent → Salesforce

The former lets you answer both “which agent?” and “on whose authority?”

3. Microsoft Entra Agent ID — compelling if you're already Microsoft-heavy

Microsoft now has a purpose-built agent identity layer with agent blueprints/identities, lifecycle governance, Conditional Access, Identity Protection and auditing.

If your estate is heavily Entra + Azure + Microsoft 365, I'd put this near the top of the evaluation rather than introducing another identity plane.

4. AWS-native stack — compelling for an AWS estate

AWS's current agentic-AI guidance explicitly calls for distinct agent identities, short-lived credentials, permission boundaries, user-context propagation and continuous permission validation.

If you're predominantly AWS, I'd evaluate the native IAM/AgentCore direction before introducing another workload-identity vendor.

5. Pomerium / agent gateway approach — interesting at the enforcement point

Pomerium is positioning around runtime access enforcement for agents/MCP, while other vendors focus more on discovering and governing the non-human identities themselves. That's an important architectural distinction.

For thousands of agents, I'd want a gateway/policy enforcement point even if identity comes from another system.

The architecture I'd actually build

I'd aim for something like:

                    Human / Event / Schedule
                              │
                              ▼
                       ┌─────────────┐
                       │ Agent       │
                       │ Identity    │
                       └──────┬──────┘
                              │
                    short-lived identity
                              │
                              ▼
                    ┌──────────────────┐
                    │ Authorization    │
                    │ Policy Engine    │
                    │                  │
                    │ user + agent +   │
                    │ task + tool +    │
                    │ resource + risk  │
                    └────────┬─────────┘
                             │
                    allow / deny / step-up
                             │
                             ▼
                    ┌──────────────────┐
                    │ Tool/API Gateway │
                    │ MCP / REST / DB  │
                    └────────┬─────────┘
                             │
                             ▼
                       Enterprise data

And every important request should produce an immutable-ish audit chain:

human → agent → delegated authority → policy decision → tool → resource → result

That attribution becomes extremely important once agents operate autonomously. AWS specifically recommends keeping agent and human permissions distinct rather than allowing an agent to assume a human identity.

One design principle I'd make non-negotiable

Don't give an agent a permanent “Salesforce Admin” credential.

Instead:

Agent requests Salesforce:update-opportunity for tenant X, opportunity Y, initiated by user Z, for task T. The authorization layer decides whether that specific action is permitted and, ideally, issues a short-lived credential/token scoped to it.

This is much closer to capability-based / policy-based access than traditional RBAC. The Cloud Security Alliance's recent guidance similarly argues that ABAC/PBAC are better suited to dynamic, task-specific agent access than static roles alone.

If I were narrowing this to a 5-vendor bake-off

I'd start with:

Managing machine identity and permissions for thousands of autonomous AI agents requires treating them as dynamic, high-velocity non-human workloads rather than standard human users . A robust agent security stack bridges foundational cryptographic identity, fine-grained runtime authorization, and intent-aware traffic gateways.

Consider the following core layers for an enterprise-grade AI agent security stack:

- *What to use:* SPIFFE / SPIRE (Secure Production Identity Framework for Everyone).
- *Why:* Static API keys or long-lived client secrets fail at scale in dynamic agent environments. SPIFFE provides cryptographically verifiable, short-lived SPIFFE Verifiable Identity Documents (SVIDs) based on the agent's runtime environment, container, or host, establishing automated zero-trust proof of who the agent is without manual credential provisioning.[](https://www.youtube.com/watch?v=blmAkayzE8M&t=633) [[1]](https://www.youtube.com/watch?v=blmAkayzE8M&t=633)[[2]](https://www.paloaltonetworks.com/blog/identity-security/ai-agent-security-spiffe-machine-identity/)

- *What to use:* OAuth 2.0 with OAuth Token Exchange (RFC 8693) and Dynamic Client Registration.
- *Why:* Agents often act on behalf of a human user or another agent. Token exchange allows you to preserve the **chain of custody** and delegation lineage (ensuring an agent cannot escalate privileges beyond the originating human or peer context). Pair this with standards emerging around protocols like the Model Context Protocol (MCP) authorization specs.[](https://umarcode.com/insights/ai-agent-identity-authorization-2026) [[1]](https://umarcode.com/insights/ai-agent-identity-authorization-2026)[[2]](https://www.youtube.com/watch?v=blmAkayzE8M&t=633)

- *What to use:* AI/API Gateways integrated with Fine-Grained Authorization (FGA) engines (e.g., Open Policy Agent / Styra or SpiceDB).
- *Why:* Agents should never hold raw, high-privilege tokens directly in their context windows, which leaves them vulnerable to prompt injection exploits. An AI gateway sits in front of external tools and APIs to strip, inspect, and re-evaluate tokens, filtering tool calls dynamically based on real-time intent and strict policy constraints.[](https://www.youtube.com/watch?v=foxmmgyu9jI&t=898) [[1]](https://www.youtube.com/watch?v=foxmmgyu9jI&t=898)[[2]](https://www.youtube.com/watch?v=aZGZen505EY&vl=en&t=29)

- *What to use:* SIEM/CNAPP tooling augmented with agentic telemetry (tracking tool-call velocity, data exfiltration patterns, and anomalous API chains).
- *Why:* Zero trust for agents requires continuous re-evaluation of intent rather than a one-time authentication check. If an agent's behavior deviates or falls victim to indirect prompt injection, the security stack must revoke its SVID and active tokens in real time.[](https://www.youtube.com/watch?v=aZGZen505EY&vl=en&t=29) [[1]](https://www.youtube.com/watch?v=aZGZen505EY&vl=en&t=29)

To help narrow down or build out this architecture, tell me:

• Are these agents internal automation tools or customer-facing agents?
• Are they deployed across multi-cloud/Kubernetes , or serverless/edge environments?
• What protocols or frameworks (like MCP , LangChain, or custom APIs) are you using for tool calling?

For thousands of AI agents, treat each agent as a non-human workload identity with its own lifecycle, permissions, and audit trail—not as a user with an API key. The stack usually needs several layers: cryptographic identity, authorization, secrets, policy enforcement, and governance.

A reference architecture:

1. Machine identity layer (the foundation)

Goal: Every agent instance can prove what it is.

Consider:

• SPIFFE + SPIRE - Short-lived workload identities (SVIDs)
• mTLS between agents/services
• No shared API keys
• Identity tied to workload attestation and runtime context

Red Hat Emerging Technologies GitHub- Cloud-native alternatives/complements: - AWS IAM Roles Anywhere / IAM workload identity patterns

• Microsoft Entra ID workload identities
• Google Cloud Workload Identity Federation
• Kubernetes service account federation

For a fleet of thousands of agents, avoid:

• Shared service accounts
• Long-lived API tokens
• "One bot identity per department"

Those make attribution and revocation difficult.

---

2. Authorization layer (what an agent may do)

Identity answers "who is calling?" Authorization answers "what can it do?"

Use:

• Policy-as-code:

• Open Policy Agent (OPA)

• Cedar policy language

• Zanzibar-style authorization models

• Fine-grained permissions:

• Agent identity

• Human delegator (if applicable)

• Task context

• Data classification

• Environment

• Risk signals

Example policy:

Agent: invoice-processing-agent
Allowed:
  - read invoices
  - create payment proposals

Denied:
  - approve payments
  - modify vendor bank accounts

---

3. Delegation and user context

Many enterprise agents act on behalf of people, so you need two identities:

1. Agent identity

• "Which autonomous worker is acting?"

2. User delegation identity

• "Whose authority is being exercised?"

Common pattern:

Human user
    ↓
Agent runtime
    ↓
Short-lived delegated token
    ↓
Enterprise API

Use:

• OAuth 2.0 token exchange (RFC 8693)
• Short-lived scoped tokens
• Proof-of-possession tokens where possible

OAuth alone is not an agent identity system; it is an authorization mechanism.

---

4. Agent runtime security

You also need controls around the agent execution environment:

Consider:

• Sandboxed execution:

• Containers

• MicroVMs

• gVisor

• Firecracker

• Tool-call gateways:

• Every tool invocation passes through policy enforcement

• No direct database/cloud credential access

• Agent isolation:

• Separate identities per agent instance

• Separate trust boundaries for high-risk agents

---

5. Secrets and credential management

Agents should rarely see raw secrets.

Use:

• HashiCorp Vault
• Cloud secret managers
• Dynamic credential issuance

Pattern:

Agent requests access
        ↓
Policy engine approves
        ↓
Credential minted
        ↓
Credential expires automatically

Avoid:

ENV=PRODUCTION_API_KEY=xxxxxxxx

---

6. Agent governance and lifecycle

At thousands of agents, you need an "agent IAM" control plane:

Track:

• Agent owner
• Business purpose
• Model/version
• Tools allowed
• Data access scope
• Deployment location
• Expiration date
• Risk classification

Capabilities:

• Agent registration
• Approval workflows
• Kill switch
• Continuous access review
• Audit logs

This is the emerging non-human identity governance problem.

---

Example enterprise stack

---

Vendors/projects worth evaluating

• SPIFFE / SPIRE — identity substrate
• HashiCorp — secrets, service mesh, policy tooling
• Microsoft Entra Agent Identity research — agent identity governance patterns
• Google Cloud — workload identity federation patterns
• Amazon Web Services — IAM workload identity patterns
• OPA/Cedar ecosystems — authorization

---

For a 10,000+ agent environment, I would prioritize:

1. SPIFFE/SPIRE (or equivalent) for every agent identity
2. Short-lived credentials only
3. Policy engine enforcing least privilege
4. Human-to-agent delegation with audit lineage
5. Agent registry + lifecycle governance

The key architectural shift is: agents become first-class principals in your IAM system, not scripts with credentials.

Securing thousands of autonomous AI agents requires shifting away from static human IAM and basic service accounts. Because agents operate at machine speed, make dynamic decisions, and inherit complex delegation chains, you need a specialized Non-Human Identity (NHI) and Agentic Security stack.

A comprehensive security stack for thousands of AI agents encompasses the following foundational layers:

• 1. Machine Identity & Cryptographic Attestation: Move beyond long-lived API keys. Implement verifiable, dynamic identities using frameworks modeled around Decentralized Identifiers (DIDs) or enterprise extensions like Microsoft Entra Agent ID . Every agent instance needs a cryptographic root of trust at spin-up to prove its provenance, model weights version, and parent orchestrator.
• 2. Secrets Management & Ephemeral Token Issuance: Integrate with automated enterprise vaults (such as HashiCorp Vault, CyberArk, or cloud-native secrets managers) to ensure agents use short-lived, dynamic tokens. Hardcoded credentials should be entirely eliminated from agent runtimes.
• 3. Fine-Grained, Context-Aware Authorization (ReBAC/ABAC): Traditional Role-Based Access Control (RBAC) breaks down when agents dynamically chain tasks. Adopt Relationship-Based Access Control (ReBAC) or Attribute-Based Access Control (ABAC) engines (such as Open Policy Agent / Cedar) to evaluate permissions in real time based on user context, data classification, and the agent's immediate goal.
• 4. Secure Intermediaries & Tool Isolation: Never let an AI agent hold direct, high-privilege credentials to production databases or external APIs. Isolate agents by forcing them to call secure intermediary services (like restricted microservices or cloud functions) that validate and scope down the agent's intent before executing commands.
• 5. AI-Specific Posture Management & Guardrails: Deploy data security posture management (DSPM) and conversational guardrails (such as Microsoft Purview or specialized model firewalls) to inspect agent inputs/outputs, prevent prompt injection data exfiltration, and enforce data loss prevention (DLP).
• 6. Unified Observability & Behavior Monitoring: Route all agent transaction logs, tool calls, and state transitions into a centralized SIEM (like Microsoft Sentinel or Datadog) configured with anomaly detection to spot rogue agent behavior, unauthorized lateral movement, or data harvesting loops.

To help narrow down the right vendors and architectural patterns for your environment, tell me:

• Are these agents built on a specific framework (e.g., LangChain, Semantic Kernel, AutoGen)?
• Is your infrastructure primarily hosted in a single cloud (AWS, Azure, GCP ) or multi-cloud/on-prem?
• Do these agents handle external third-party APIs or strictly internal enterprise data?

For thousands of AI agents, I’d avoid treating “agent security” as a standalone product category. The durable architecture is workload identity + delegated human identity + fine-grained authorization + short-lived credentials + runtime enforcement + audit.

Stack I’d evaluate

My shortlist

1. Aembit — strongest fit if machine identity is the centerpiece.

Aembit treats agents as workloads rather than inventing a separate identity model. Its model combines an agent's workload identity with the human identity behind it (“blended identity”), then issues short-lived credentials and enforces policy. Its MCP Identity Gateway can keep backend credentials completely away from the agent.

That makes it particularly interesting for a population of thousands of heterogeneous agents spanning cloud, SaaS, on-prem and MCP.

2. Okta for AI Agents — strongest if you already run Okta.

Okta's current AI-agent offering is GA and focuses on registering/governing agents, least privilege, time-bound access, centralized visibility and revocation. Its model is particularly compelling for workforce-driven agents where the human identity is central.

3. SPIFFE/SPIRE + Cedar/OPA — strongest build-your-own foundation.

For an engineering-heavy organization, I'd seriously consider making SPIFFE the machine-identity substrate and Cedar or OPA the authorization layer. AWS has specifically documented Cedar for preventing privilege expansion through multi-agent chains—exactly the problem that becomes dangerous when agents delegate to other agents.

The advantage is avoiding dependence on a single agent-security vendor. The disadvantage is that you own the identity lifecycle, credential exchange, policy management, gateways, integrations and operational UX.

The architecture I'd target

                    ┌─────────────────────┐
                    │   Human / Workload   │
                    │      Identity        │
                    └──────────┬──────────┘
                               │
                         delegated authority
                               │
                    ┌──────────▼──────────┐
                    │    Agent Identity   │
                    │ SPIFFE / workload   │
                    │       identity      │
                    └──────────┬──────────┘
                               │
                     agent + user + task
                               │
                    ┌──────────▼──────────┐
                    │ Authorization / PDP  │
                    │ Cedar / OPA / IAM    │
                    └──────────┬──────────┘
                               │
                    short-lived JIT access
                               │
                    ┌──────────▼──────────┐
                    │ Agent/MCP/API Gateway│
                    │  policy enforcement │
                    └─────┬──────┬────────┘
                          │      │
                       Jira   AWS/SaaS/DB

The critical design principle is:

An agent should never inherit a permanent credential simply because it was launched by an authorized user. Instead, every consequential request should answer:

Which human? Which agent? Which agent version? Which task/session? Which resource? Which action? Under what policy?

That becomes especially important with multi-agent chains, where authorization can accidentally expand as one agent delegates to another.

For thousands of agents, I'd make these non-negotiable

• Unique machine identity per agent/workload, not shared service accounts.
• Short-lived credentials, ideally minted just before use.
• No secrets in prompts, agent memory, source code or MCP configuration.
• Separate agent identity from human identity, then explicitly bind them for delegated actions.
• Task/action-scoped authorization, rather than merely “this agent can access Salesforce.”
• Policy evaluation at the resource boundary, not just inside the agent framework.
• Delegation attenuation: an agent cannot grant its child agent more privilege than it possesses.
• Instant revocation by identity/policy rather than credential rotation.
• Complete attribution: human → agent → child agent → tool → resource → action.
• A kill switch for an individual agent, agent class, credential, or tool integration.

Aembit's current architecture is particularly aligned with those requirements: its documentation explicitly describes per-user credential scoping, short-lived tokens, blended identity, centralized audit and policy-based revocation.

If I were choosing a starting point: I'd run a bake-off between Aembit vs. your existing enterprise IdP + SPIFFE/SPIRE + Cedar/OPA, and add Okta for AI Agents if Okta is already your identity control plane. The deciding test should be whether each can safely authorize 10,000 agents making delegated, multi-hop tool calls without giving those agents standing credentials.

Aembit treats agents as workloads rather than inventing a separate identity model. Its model combines an agent's workload identity with the human identity behind it (“blended identity”), then issues short-lived credentials and enforces policy. Its MCP Identity Gateway can keep backend credentials completely away from the agent.

That makes it particularly interesting for a population of thousands of heterogeneous agents spanning cloud, SaaS, on-prem and MCP.

2. Okta for AI Agents — strongest if you already run Okta.

Okta's current AI-agent offering is GA and focuses on registering/governing agents, least privilege, time-bound access, centralized visibility and revocation. Its model is particularly compelling for workforce-driven agents where the human identity is central.

3. SPIFFE/SPIRE + Cedar/OPA — strongest build-your-own foundation.

For an engineering-heavy organization, I'd seriously consider making SPIFFE the machine-identity substrate and Cedar or OPA the authorization layer. AWS has specifically documented Cedar for preventing privilege expansion through multi-agent chains—exactly the problem that becomes dangerous when agents delegate to other agents.

The advantage is avoiding dependence on a single agent-security vendor. The disadvantage is that you own the identity lifecycle, credential exchange, policy management, gateways, integrations and operational UX.

The architecture I'd target

                    ┌─────────────────────┐
                    │   Human / Workload   │
                    │      Identity        │
                    └──────────┬──────────┘
                               │
                         delegated authority
                               │
                    ┌──────────▼──────────┐
                    │    Agent Identity   │
                    │ SPIFFE / workload   │
                    │       identity      │
                    └──────────┬──────────┘
                               │
                     agent + user + task
                               │
                    ┌──────────▼──────────┐
                    │ Authorization / PDP  │
                    │ Cedar / OPA / IAM    │
                    └──────────┬──────────┘
                               │
                    short-lived JIT access
                               │
                    ┌──────────▼──────────┐
                    │ Agent/MCP/API Gateway│
                    │  policy enforcement │
                    └─────┬──────┬────────┘
                          │      │
                       Jira   AWS/SaaS/DB

The critical design principle is:

An agent should never inherit a permanent credential simply because it was launched by an authorized user. Instead, every consequential request should answer:

Which human? Which agent? Which agent version? Which task/session? Which resource? Which action? Under what policy?

That becomes especially important with multi-agent chains, where authorization can accidentally expand as one agent delegates to another.

For thousands of agents, I'd make these non-negotiable

Managing machine identity and permissions for thousands of autonomous AI agents requires moving beyond the traditional human-centric IAM playbook . Because AI agents reason dynamically, chain tools on the fly, and operate continuously, legacy static API keys and shared service accounts create an untenable "non-human insider" risk.

A production-grade security stack for thousands of AI agents must be built across four core architectural layers:

1. Agent Identity Issuance & Cryptographic Attestation

• SPIFFE/SPIRE: Essential for zero-trust workload identity, providing ephemeral, cryptographically verifiable X.509 certificates or JWTs to agents at runtime based on workload attestation rather than static secrets.
• OAuth 2.0 / OIDC with Token Exchange (RFC 8693): Treat agents as first-class OAuth clients rather than masking them behind human credentials. Use token exchange to pass the original user's delegation context securely down the line, preventing the "confused deputy" problem where an agent exceeds user intent.
• Specialized NHI & Agent Identity Platforms: Emerging tools and features from vendors like Token Security, CyberArk AI Credentials Governance , and enterprise IAM extensions (such as Ping Identity and Strata Identity ) explicitly inventory, assign ownership, and govern agent lifecycles.

2. Runtime Interception & Tool-Level Access Gateways

• Model Context Protocol (MCP) Gateways & Agent Gateways: Deploy a proxy/gateway layer (like Google Cloud's Agent Gateway) to inspect agent-to-tool and agent-to-agent interactions in real time. This ensures policies are enforced at the point of interaction , restricting what databases or APIs an agent can reach.
• Just-In-Time (JIT) / Zero Standing Privileges (ZSP): Integrate with privileged access management platforms (such as Delinea or Britive ) to issue vaultless, short-lived, task-scoped permissions that expire the moment the agent completes its execution thread.

3. Isolation & Execution Runtimes

• Secure Runtimes & Hardware Enclaves: Isolate agent execution environments below the framework level using secure runtimes like NVIDIA OpenShell or microVMs. System prompts are advisory, not security boundaries; actual containment must happen at the OS, container, or hypervisor layer.

4. Behavioral Observability & AI-EDR

• Telemetry & Unified Logging: Route all agent actions, delegation chains, and tool-call intents to an OpenTelemetry (OTel)-compatible SIEM.
• Behavioral Baselining / Anomaly Detection: Track baseline metrics for individual agents (normal volume of data read, typical API paths) to immediately spot prompt-injection side-effects, data exfiltration, or sudden behavioral drift.

To help narrow down the ideal architecture, could you share:

• Are these agents interacting with external systems via Model Context Protocol (MCP) or custom APIs?
• Do you need them to operate under delegated human consent (acting on behalf of a user) or as independent autonomous services?

Managing machine identity and permissions for thousands of AI agents requires moving past traditional service accounts and static API keys . Because AI agents reason dynamically, act quickly, and often operate via delegated authority (acting on behalf of a human user or another orchestrator), legacy IAM breaks down.

A production-grade Agentic Security Stack is organized into four distinct layers:

• 1. Agent Identity & Lifecycle Plane (Issuing Cryptographic IDs)
  • Use dedicated Non-Human Identity (NHI) and workload identity platforms (such as Microsoft Entra Agent Identity, Okta / Auth0 for AI Agents, Ping Identity , or Aembit ) to provision unique, non-transferable cryptographic identities for every agent.
  • Enforce mandatory metadata tagging to assign both a business owner and a technical owner to every agent to eliminate "ghost" or orphaned agents.
• 1. Delegation & Token Vault Layer (Handling "On-Behalf-Of" Flows)
  • Standardize on OAuth 2.1 with PKCE and JWT bearer assertions carrying explicit delegation chains.
  • Implement an enterprise Token Vault (like Auth0 Token Vault) so that agents never store raw, long-term credentials or user tokens in memory; instead, they exchange short-lived, task-scoped tokens dynamically.
• 1. Tool & Gateway Enforcement (Governing the Model Context Protocol - MCP)
  • Position an MCP Gateway / AI Gateway between your agent runtimes and downstream tools/APIs.
  • Enforce Zero Standing Privilege (ZSP) and default-deny tool allowlists—meaning the agent starts with zero tool access and dynamically requests capabilities only for the active step of a workflow.
  • Use fine-grained authorization frameworks (such as OpenFGA or Auth0 FGA) to evaluate down-stream permissions (e.g., checking if the specific user-agent combination is authorized to read a specific RAG document or execute an API write).
• 1. Runtime Behavioral & Posture Layer (Catching Drift & Prompt Injection)
  • Deploy agentic posture and runtime security tools (such as Palo Alto Networks Prisma AIRS, Cisco Secure Access, or specialized AI EDR solutions) to monitor the sequence of tool calls in real time.
  • Implement Asynchronous Authorization (Human-in-the-Loop) workflows for high-impact or irreversible actions (like money transfers, data deletion, or external emails), halting the agent session until explicit approval is granted.

To help tailor this stack to your infrastructure, could you share:

• Where are your agents primarily hosted (e.g., AWS, Azure, multi-cloud, or custom on-prem infrastructure)?
• Are these agents primarily autonomous (client-credentials/background workers) or attended (acting directly on behalf of logged-in end users)?

For thousands of AI agents, I’d avoid treating agents as ordinary API keys or service accounts. The stack should separate machine identity, authorization, delegation, and runtime enforcement.

My recommended architecture

The interesting choice: Cedar vs. OpenFGA

I'd lean Cedar if your primary problem is policy. It handles RBAC/ABAC-style decisions and explicitly separates authorization logic from application logic. AWS's current agentic-AI guidance is actually using a three-layer Cedar model: agent→tool, agent→agent delegation, and originating-user authority.

I'd lean OpenFGA if your primary problem is resource relationships. For example:

Agent-17 can edit Project-42 because it is delegated by User-9, who is an editor of Project-42.

OpenFGA now has explicit agent-authorization patterns, including treating agents as principals and issuing task-specific permissions with expiration/turn limits.

You can also combine them: Cedar at the infrastructure/admission boundary + OpenFGA for application/resource authorization is a sensible architecture for complex enterprises.

What I'd build

                    Human / Application
                           │
                     OIDC / OAuth
                           │
                           ▼
                    ┌─────────────┐
                    │ Agent A     │
                    │ SPIFFE ID   │
                    └──────┬──────┘
                           │
                 delegation token
                 + original user
                 + task constraints
                           │
                           ▼
                 ┌─────────────────┐
                 │ Policy Gateway  │
                 │                 │
                 │ Identity: SPIFFE│
                 │ AuthZ: Cedar/FGA│
                 │ Limits: TTL/hops│
                 └───────┬─────────┘
                         │
             ┌───────────┼───────────┐
             ▼           ▼           ▼
          Agent B      MCP tool    Database
          SPIFFE ID    SPIFFE ID   dynamic cred

The key design principle is identity ≠ permission.

A SPIFFE identity might say:

spiffe://company/agents/researcher-17

That establishes who/what the workload is. It should not inherently mean "can read all customer data."

The authorization request should instead look conceptually like:

principal: agent/researcher-17
action:    read
resource:  customer/12345
context:
  originating_user: user/987
  task_id: task/abc
  delegation_depth: 2
  environment: production
  purpose: customer-support

Then your PDP makes the deterministic allow/deny decision.

For agent-to-agent delegation, be especially strict

This is where conventional IAM architectures tend to break down. If Agent A has permission to call Agent B, you don't want B automatically inheriting all of A's authority.

I'd enforce:

1. Maximum delegation depth
2. Expiration/TTL on every delegation
3. Capability narrowing only — child authority can never exceed parent authority
4. Explicit allowed tools/actions
5. Resource/tenant constraints
6. Original human identity preserved
7. Non-repudiable delegation chain
8. Policy decision at every sensitive tool invocation

AWS's recent multi-agent Cedar reference architecture follows essentially this model, including checking delegation depth and ensuring requested capabilities are a subset of the target agent's registered capabilities.

What I would shortlist

Open-source / portable

• SPIFFE + SPIRE — machine identity.
• Cedar — policy engine/language.
• OpenFGA — relationship/resource authorization.
• OPA — another strong policy-engine option, particularly if you already have Kubernetes/cloud-native policy infrastructure.

Managed alternatives

• Amazon Verified Permissions + Cedar if you're heavily AWS-oriented; it provides a managed Cedar authorization service.
• Your existing enterprise IdP for human identity, but I would not use the human IdP alone as the machine-identity system.

If I were designing this from scratch

My default stack would be:

SPIFFE/SPIRE → mTLS/JWT-SVID → Cedar → OpenFGA where resource relationships demand it → policy-enforcing gateway → dynamic secrets → centralized audit.

That gives you a clean division:

SPIFFE: Who is this agent?
Cedar: Is this action permitted under policy?
OpenFGA: Does this agent/user have a relationship to this particular resource?
Delegation token: What authority was actually handed to this agent for this task?
Gateway: Did the request satisfy all of those controls before the tool executes?

For thousands of agents, that separation is much more scalable than creating thousands of bespoke IAM roles and API keys. SPIFFE is specifically designed for portable cryptographic workload identity across heterogeneous environments.

If you're deciding this for an actual platform, the next useful step is to compare SPIRE vs. cloud-native workload identity, Cedar vs. OPA vs. OpenFGA, and Vault/cloud secret managers against your Kubernetes/cloud/MCP architecture and produce a concrete reference stack.

Yes. For thousands of AI agents, I’d avoid treating this as “IAM for a new type of user.” I’d build an agent/workload identity + fine-grained authorization + credential-brokering stack.

The architecture I’d target

1. Machine identity — give every agent a cryptographic workload identity

Use SPIFFE/SPIRE as the underlying identity primitive if you want an open, portable foundation. SPIRE performs node/workload attestation and issues short-lived SPIFFE identities to workloads; SPIFFE supports X.509 and JWT workload credentials.

Conceptually:

agent → attestation → workload identity → short-lived credential

Don't give 10,000 agents API keys or shared service accounts.

2. Human + agent identity — preserve delegation

For user-driven agents, every request should carry something like:

human = Alice
agent = security-investigator-v7
tenant = Acme
task = investigate-alert-123
resource = CrowdStrike

This is important because “Alice did it” isn't enough. You need to know which agent acted on Alice's behalf. Aembit calls this blended identity, combining the human IdP identity with the agent's workload identity.

For autonomous agents, there may be no human identity—use the agent/workload identity plus its delegated authority and task context.

3. Authorization — make permissions first-class

I'd strongly consider Cedar for application-level authorization. It supports fine-grained policies over principals, actions, resources and context, including RBAC and ABAC, and keeps authorization logic separate from application code.

For example:

permit(
  principal == Agent::"invoice-agent",
  action == Action::"read",
  resource == Invoice::*
)
when {
  principal.tenant == resource.tenant &&
  principal.task_type == "accounts-payable"
};

You can also use OPA/Rego if your organization already has a strong Kubernetes/cloud-policy investment there. OPA is particularly useful as a general policy engine across APIs, Kubernetes, CI/CD and infrastructure.

I wouldn't run both Cedar and OPA everywhere. Pick one primary authorization model.

4. Credential broker — agents should not possess standing secrets

This is probably the most important operational layer.

Instead of:

Agent → API key → Salesforce

do:

Agent identity → policy decision → credential broker → short-lived credential → Salesforce

The agent should ideally never see the underlying long-lived credential.

This is where products such as Aembit are particularly relevant. Its current architecture combines workload attestation, policy, JIT credentials, credential isolation and agent+user identity, including an MCP identity gateway.

5. Human identity / lifecycle

Keep your existing enterprise IdP—e.g. Okta or Entra—as the human identity authority, rather than trying to make your agent platform replace it.

Okta is now explicitly positioning around AI/non-human identity, including agent discovery, token vaulting, fine-grained authorization and lifecycle management.

The distinction I'd maintain is:

Vendors/stacks I'd evaluate

If you're building a platform team / want maximum control

SPIFFE/SPIRE + Cedar + your existing IdP + Vault/cloud secret stores + API/MCP gateway

This gives you a relatively clean separation of identity and authorization.

If you want a commercial workload/agent IAM layer

Aembit + existing IdP + Cedar/OPA + SIEM

Aembit is unusually aligned with your specific problem because it treats agents as non-human workloads and provides JIT credentials and policy enforcement rather than simply putting another API gateway in front of them.

If you're heavily AWS-centric

AWS IAM + Bedrock AgentCore Identity + Cedar/Verified Permissions

AWS's AgentCore documentation specifically recommends its Identity capability for securing third-party credentials and distinguishes user-delegated OAuth authorization from autonomous client-credentials authentication. docs.aws.amazon.com AWS's Verified Permissions uses Cedar for fine-grained application authorization and recognizes machines as principals.

If you're heavily Okta-centric

Okta/Entra + Okta AI identity capabilities + workload identity provider + Cedar/OPA

This is attractive when agent lifecycle, ownership, discovery and human delegation are as important as machine-to-machine authentication. Okta's current AI security architecture explicitly covers agent registration, ownership, token management and granular access.

One architectural rule I'd make non-negotiable

Don't model permissions as “what can this agent access?”

Model them as:

Who/what is acting → on whose behalf → for what purpose → against which resource → with which action → under what runtime conditions → for how long?

That lets you express policies such as:

Agent X may read Jira issues for User Y, but only within Tenant Y, only for an incident-response task, only against projects A/B, and only with a 15-minute credential.

That is much more scalable than creating thousands of agent-specific RBAC roles.

My shortlist

If I were doing a serious evaluation today, I'd put Aembit, SPIFFE/SPIRE, Okta, AWS AgentCore, Cedar/Verified Permissions, and OPA on the architecture matrix—but they aren't all competitors. They're different layers.

For 10k+ agents, my preferred conceptual stack would be:

SPIFFE/SPIRE (identity) → Cedar (authorization) → Aembit or equivalent (credential brokering/enforcement) → MCP/API gateways → SIEM

with Okta/Entra remaining the human identity plane.

The critical evaluation criterion isn't “does it support AI agents?” It's can you create, attest, authorize, revoke and audit 10,000+ distinct non-human identities without distributing 10,000+ permanent secrets?

Managing machine identity and permissions for thousands of autonomous AI agents breaks traditional Identity and Access Management (IAM). Legacy tools were built for deterministic, static service accounts or human sessions—not for probabilistic, multi-step agents that chain tools together and operate at machine speed.

To secure thousands of agentic identities without halting productivity, you need an Agentic IAM Stack built around zero standing privileges, ephemeral credentials, and strict delegation chains.

Layer 1: Identity Governance & Lifecycle (The Registry)

• Core Problem: Shadow AI and orphaned service accounts. Agents get spun up by developers, accumulate broad permissions, and are forgotten.
• What to Consider:
  • Identity Security Posture Management (ISPM) / Non-Human Identity (NHI) Discovery: Platforms like Oasis Security or Entro Security to continuously discover and catalog every agent, its data paths, and connected tools.
  • Mandatory Human Accountability: Enforce that every agent identity has an explicit human owner tied into your HR/Directory system. If the owner leaves or changes roles, the agent is automatically flagged for review or sunsetted.

Layer 2: Authentication & Delegated Authority

• Core Problem: Agents shouldn't share broad service accounts or impersonate users using long-lived API keys or stolen master tokens.
• What to Consider:
  • Workload Identity Federation & OAuth Token Exchange: Use standards like OAuth 2.0 Token Exchange (RFC 8693) to pass an audit trail from the initiating human user down to the agent. The agent acts via delegated authority , meaning it receives a constrained token representing both its own identity and the user's explicit scope.
  • Asymmetric, Key-Bound Credentials: Prefer short-lived JWTs or X.509 certificates with mutual TLS (mTLS) over static, symmetric API keys.

Layer 3: Dynamic Authorization & Least Privilege

• Core Problem: Static Role-Based Access Control (RBAC) is too coarse. An agent reading an S3 bucket shouldn't have listing or writing rights globally.
• What to Consider:
  • Fine-Grained Authorization (FGA) & ReBAC/ABAC: Implement Attribute-Based or Relationship-Based Access Control. Evaluate context dynamically at runtime: What is the agent's current goal? What task boundary was it assigned?
  • Just-In-Time (JIT) & Zero Standing Privileges (ZSP): Don’t let agents hold permanent tokens. Mint micro-scoped, ephemeral credentials on the fly for a single tool call or action block, then revoke them immediately.
  • Model Context Protocol (MCP) Security Gateways: If your agents use Model Context Protocol (MCP) to talk to internal databases and tools, put an authorization-aware proxy or tool gateway in front of them to intercept and downscope every single call.

Layer 4: Runtime Observation & Guardrails

• Core Problem: A prompt-injection attack can hijack an agent's goals, turning a helpful assistant into a high-speed malicious actor.
• What to Consider:
  • Behavioral Anomaly Detection: Track deviations in real-time (e.g., an agent suddenly attempting to pull records from unauthorized schemas or mass-export data).
  • Continuous Access Evaluation (CAEP): Leverage the Shared Signals Framework to revoke an agent's active tokens instantly if its underlying behavior or safety posture trips an alarm.
  • Human-in-the-Loop (HITL) Checkpoints: Automatically trigger out-of-band approval flows (via CIBA or secure messaging hooks) whenever an agent encounters a high-risk action like data deletion or financial transfers.

To help narrow down the best stack or vendors for your environment, tell me:

• Are your AI agents built in-house using orchestrators (like LangChain, Semantic Kernel), or are you deploying commercial agent frameworks?
• Are they interacting with enterprise tools primarily via APIs or through Model Context Protocol (MCP) servers?