Securing the agentic enterprise: The blueprint in practice

Agents are powerful. They're also an attack surface.

An AI agent is only as useful as the systems you let it into. The useful ones are out approving refunds, posting transactions, and changing customer records in the systems you protect most carefully, reached through SaaS connectors, Model Context Protocol (MCP) servers, and APIs. 

To act, an agent has to be trusted by systems it has never met, on someone else's behalf, with no human watching the moment it decides. A single agent under supervision is easy to understand and control (Figure 1). 

The trouble starts as agents graduate from pilots to production and adoption scales across the company. One supervised connection becomes thousands of unsupervised ones. The authority granted to each is set once and set broadly, resulting in access chaos (Figure 2).

One agent. Many tools and resources.

Every link reaches your customer data, your IP, and the operational systems that run your business.

Users × agents × conversations × tools = Access chaos

Every link is an attack surface. Authorization has to govern each one, on every call, at machine speed.

That chaos looks like a security threat, but threats come from the outside. Agents don't break in; they are already inside—they are created, connected to, or granted access to a system. By the time traffic reaches a firewall, the agent is already inside. 

The real question is what happens next: 

• Which agent is this?
• Who authorized it?
• What can it reach? 
• What can it do for this task? 
• How do we revoke its access?

These are identity and authorization questions, and while coarse scopes can be determined up front, they can’t be answered in advance; per-task decisions must be made at runtime. An agent's authority must be determined at the moment of action, based on both the human and agent identities. This ensures that authorization is precisely scoped to the task and that the accountable human is linked to every request. This core principle serves as the foundation for the entire architecture.

The security blueprint exists. The budget doesn't.

The shift is already visible at the leading edge. Uber recently published a detailed account of how it gave agents a real identity, landing on cryptographic agent identity and a per-hop token exchange that carries the actor chain from the human through to the tool. It is a strong validation that the problem is real and the architecture is knowable. It also took an engineering organization that most enterprises will never have, built and operated in-house. 

The lesson worth drawing is about standards: An identity layer for agents only holds if it travels across the vendor and SaaS boundaries agents cross constantly, which means it has to be built using consistent standards that every party implements the same way and delivered as a layer rather than engineered company by company. That is what Okta for AI Agents is.

How Okta secures the agentic enterprise

Okta for AI Agents turns that principle into an operating layer: Verifiable identity for every agent, authorization decided at the moment of the action, and the accountable human carried through the chain. The rest of this post walks through the architecture using one enterprise as an example.

A typical agentic enterprise implementation 

To make this hypothetical concrete, take Streamward Inc., a composite of the enterprises we work with. A user makes a request through a chat assistant, and a master agent orchestrator parses the intent and delegates sub-tasks across the mesh by business capability (Figure 3). To access downstream systems, proprietary APIs, and third-party services, the agents use a mix of runtime resource types: MCP servers, REST endpoints governed by OpenAPI specifications, and native cloud data warehouses.

Sample multi-agent mesh architecture

• Salesforce Agentforce: Handles CRM pipeline analysis, lead scoring, and account lookups.
  • Connected MCP server: ross-references Salesforce account IDs against live billing through an enterprise ERP MCP server, calling get_customer_payment_history.
• Amazon Bedrock AgentCore: Runs retrieval-augmented generation (RAG) over corporate knowledge.
  • Connected MCP server: Connects to an AWS Aurora PostgreSQL vector database through MCP to run semantic searches, calling query_knowledge_base and fetch_unstructured_contract_pdf.
• Google Vertex AI: Low-code runtimes driving autonomous customer workflows.
  • Connected OpenAPI gateway: Routes calls through an OpenAPI-compliant Workday and ServiceNow gateway, calling read_latest_incident_tickets and triggering create_workday_expense_claim.

The four common security gaps in the implementation

Now we’ll trace one ordinary request through this mesh to highlight common security gaps: A corporate knowledge-base lookup that must reach the database. Without a central identity fabric, it fails in four ways, as seen in the token the agent carries (Figure 4). The gap is in what the token is missing.

Shadow AI 

Homegrown or third-party agents running inside Amazon Bedrock AgentCore are frequently configured or deployed by teams without registering them through the identity provider (IdP). Because a security SDK isn’t injected into these environments, the agents dynamically spin up and connect to internal resources around the edges of corporate access policies. Their raw tokens show a machine client but lack an iss (issuer) claim, no validating human behind them, and no owner responsible for their lifecycle. You simply cannot govern a Bedrock agent you never issued.

Over-privileged access 

The scope claim in an unmanaged agent's token exposes excessive risk. To let the Bedrock agent connect down to the target database without constantly interrupting the execution flow to re-authenticate across system boundaries, developers tend to assign the agent to a broad, long-lived service account. The token's scope covers a permanent, wide administrative surface far beyond what a specific text query needs. Every oversized scope creates an access path vulnerable to prompt injection or data exfiltration, yet revoking the agent breaks every other automated workflow sharing that single service account.

Impersonation, not delegation

As the lookup crosses from Bedrock AgentCore into the target Aurora DB MCP server, identity completely collapses into a generic machine principal. The database engine logs a service account calling query_knowledge_base(), missing the identity of the human operator who initiated the task and the specific sub-agent executing the query. Without cryptographic delegation lineage inside the token, the resource boundary cannot enforce user-level data permissions, resulting in complete identity erasure and a broken audit trail.

No governance

When the agent fires a tool invocation or an unexpected database read, the unmanaged machine token carries neither transaction identity nor context of human consent. The action executes seamlessly with no runtime pause for approval, leaving security teams completely in the dark. After the fact, it becomes impossible to cryptographically link the automated transaction back to a human controller, meaning you cannot legally prove who authorized what data movement.

Most enterprises fix one or two of these.

The four common security gaps as seen in the token

Hold that one request in mind. The walkthrough later in this post shows the Agentcore agent accessing the Aurora DB MCP tool, this time with Okta in the path, and succeeds without any of the four failures.

Okta for AI Agents addresses the security gaps 

Okta turns the trust boundary into a governance layer embedded in the execution path (Figure 5). Streamward routes all MCP traffic through an inline Runtime Agent Gateway, the policy enforcement point (PEP), with Okta as the policy decision point (PDP) behind it. The agent never holds a raw credential for the MCP tools. This is the control-plane idea made physical: Every request stops at a point that knows the identities involved and decides, in the moment, what is allowed.

Sample multi-agent mesh architecture with Okta for AI Agents

The secure access flow, hop by hop

The final request reaching any backend tool includes a verifiable identity that holds both the human context (the sub claim) and the agent workload principal (the act claim). 

Here is the same knowledge-base query from earlier, now running through Okta. The diagram below traces it end to end, and the hops that follow walk through each step, showing how the token is built and exchanged along the way (Figure 6).

The end-to-end secure access flow

The final request reaching any backend tool carries a verifiable identity holding both the human context (the sub claim) and the agent workload principal (the cid claim). 

Hop 1: Human user to frontend

The user signs in to Streamward’s portal through an OpenID Connect (OIDC) flow, and Okta issues a standard user access token.

Hop 2: Frontend to the orchestrator

The frontend handles the natural-language prompt and passes the task context to the master agent orchestrator, carrying the user access token as a bearer token.

Hop 3: Orchestrator to Okta, A2A exchange

The orchestrator determines the task needs analytical processing in Bedrock AgentCore via the agent Corp-Knowledge-Agent It submits the user token and the requested scope to Okta’s token endpoint (/oauth2/v1/token) and initiates the Cross-App Access (XAA) flow (Identity Assertion Authorization Grant). Okta evaluates the agent access policy and returns a short-lived, one-time-use ID-JAG token (urn:ietf:params:oauth:token-type:id-jag), downscoped to the task.

Hop 4: Orchestrator to Okta, token exchange

The orchestrator creates a client assertion with the orchestrator’s private key and exchanges the ID-JAG token at the custom authorization server assigned to the target Agentcore agent. Okta evaluates the user access policy there and returns a scoped access token destined for the agent Corp-Knowledge-Agent.

Hop 5: Orchestrator to Bedrock AgentCore

The orchestrator passes the scoped token as part of the actual agent-to-agent (A2A) call to the Agentcore agent Corp-Knowledge-Agent. AgentCore verifies the token and allows the call to proceed in the context of the orchestrator agent and the initiating human identity.

Hop 6: AgentCore to the gateway

Corp-Knowledge-Agent invokes the query_knowledge_base tool on the Aurora DB MCP server through the gateway, passing the incoming token and desired permission (scope) for the outbound tool.

Hop 7: Gateway to Okta, Cross-App Access 

The gateway initiates the XAA flow again, submitting the inbound token and the requested scope to Okta’s token endpoint (/oauth2/v1/token). Okta evaluates the agent access policy and returns a short-lived, one-time-use ID-JAG token, downscoped to the task.

Hop 8: Gateway to Okta, token exchange 

The gateway creates a client assertion with the Agentcore Corp-Knowledge-Agent’s private key and exchanges the ID-JAG token at the custom authorization server assigned to the target Aurora DB MCP server. Okta evaluates the user access policy there and returns a scoped access token destined for the MCP server.

The tool at the end receives a request it can fully attribute: Who the human is, which agent acted, its scope, and a chain-of-custody claim (act) that ties the whole chain to one record. Authority was decided at runtime, scoped to the task, and never separated from the human accountable for it.

The four core security flaws solved by the architecture

By routing the Bedrock AgentCore execution flow through this standardized architecture, Streamward successfully neutralizes the four common identity errors that break unmanaged agent configurations:

Shadow AI remediation 

Rather than allowing the Bedrock Corp-Knowledge-Agent to run blindly around the central IdP without a verifiable issuer, the agent is registered directly in Universal Directory as a distinct workload principal. IT governance maintains clear ownership over its lifecycle and visibility over its network connections.

Over-privileged access remediation 

Instead of running on a broad, permanent service account with standing permissions that expose the entire database layer to prompt-injection threats, the agent is issued a short-lived token minted dynamically at runtime. Its scopes are mathematically intersected and downscoped strictly to the single database operation required for that specific execution block (Aurora-DB:read).

Impersonation prevention 

By embedding the multi-hop act delegation chain directly into the token context, identity does not collapse into a generic machine credential. The resource boundary can accurately track the lineage of custody, preventing identity erasure and enforcing data controls in accordance with the initiating human's real permissions.

Governance enforcement

Every step of the token exchange generates explicit, structured events (app.oauth2.token.grant.id_jag) tied to an immutable transaction identifier. This permanent audit history provides compliance and incident response teams with evidence of which human authorized what automated action.

The Okta for AI Agents components

Let’s look at the Okta for AI Agents components involved in the solution above.

Agent registry and discovery  

This component turns unknown autonomous agents into known, verifiable workload principals by registering them in Universal Directory, where each gets a lifecycle, a named human owner, and a place in policy. 

Because unmanaged agents appear faster than anyone can register them by hand, Identity Security Posture Management (ISPM) discovers them across clouds and MCP networks, including the no-code agents that would otherwise stay invisible, and maps each one back to an owner. An agent you cannot see is one you cannot authorize or hold to account.

Automatic agent onboarding

Agents built on Salesforce, AWS, Microsoft, and ServiceNow import directly into Universal Directory, so the registry keeps pace with their appearance.

Cross-App Access 

XAA uses the Identity Assertion Authorization Grant to prevent identity erasure across multi-hop workflows. Instead of an agent acting as an anonymous service account, the human (the sub claim) and the agent (the act claim) both travel in the token (Figure 7), producing an actor claim that is a chain rather than a single principal. XAA is what keeps authorization tied to a real human as a request crosses vendor boundaries.

The XAA flow

Brokered consent

For first-time agent-to-SaaS access on a user’s behalf, Okta’s Secure Token Service (STS) brokers consent dynamically. The agent pauses while the user authorizes access once, out of band, before the call proceeds. Consent is established at the identity layer rather than wired into each agent, so even an agent you cannot modify inherits the control.

Agent-to-agent authorization  

In an agent mesh, Okta mediates every handoff. A single step configures the connection between two agents (Figure 8), and the effective permission is the intersection of the user’s rights and the calling agent’s, meaning a sub-agent never exceeds the least-privileged combination. The nested actor claim extends from the human through each agent to the final service, with policy-controlled authority at every hop and keeping the accountable human in the chain.

Configuring the agent-to-agent resource connection in Okta

Centralized auditing

Because an agent is not a legal person and cannot answer for itself, the accountable human has to be nameable at the end of every chain. One trail captures every transaction with explicit grant events that prove who acted and on whose behalf (Figure 9), which is the record a regulator, a court, or a board will ask for.

Okta system log for centralized auditing

Secure runtime control

Okta deploys the inline Runtime Agent Gateway as the central policy enforcement point (PEP) in front of downstream resources, with Okta serving as the policy decision point (PDP) for every request (Figure 10).

The Runtime Agent Gateway

• Virtual MCP server: The gateway presents itself as an MCP server, allowing organizations to secure low-code and no-code agents that access enterprise resources without those agents needing to speak to the token exchange natively.
• Credential isolation: The gateway abstracts short-lived XAA tokens and longer-lived brokered SaaS tokens, so those resource credentials are never exposed to agents.
• Inline tool-call security: Low-code platforms route every outbound tool call through the gateway, which intercepts the call, checks the relationship with fine-grained policies at wire speed, and injects a short-lived backend secret at the edge before execution. The token it issues is minted at the moment of the request, scoped to the task, audience-bound, and revocable in seconds—the opposite of a standing credential that can be found in a file and reused.

Where this goes next: Advanced Okta for AI Agents capabilities

What this architecture provides today is the foundation: every agent gets a verifiable identity, and its authority is determined at runtime and scoped to the task. 

The first phase of a global kill switch is already in place, using the Shared Signals Framework (SSF) to turn a risk signal into revocation, which will expand to coordinated, real-time termination across every connected system, the control that short-lived tokens alone cannot provide.

What comes next is the same control-plane principle reaching the parts of an agent's life it does not yet touch, the questions governance teams already ask of human access, now asked of agents:

• Agent access certification: Ensures each agent's authority undergoes the same attestation and review as any other access, with resource owners confirming what should be retained and revoking what is stale. 
• Identity-to-resource access graph: Traces the full path from a person, through every agent acting for them, to the resources and scopes each one can reach, so the blast radius is visible before anything goes wrong and the revocation target is obvious when it does. 
• Human-in-the-loop approval: At provisioning time and when performing a sensitive action, it keeps a person in the decision-making process where it matters most. 
• Unattended authority: Agents begin to earn unattended authority based on how they have behaved, rather than on trust being granted up front.

None of this is a new control plane. It is the same one, extended from the moment an agent is created to the moment its authority is reviewed, narrowed, or withdrawn.

The blueprint for the secure agentic enterprise

Step back, and the architecture answers the three questions every security team is asking (Figure 11):

1. Where are my agents? (The ones the company built and the ones that arrived on their own.) 
2. What can they connect to? (From MCP servers and SaaS apps to other agents, service accounts, and legacy systems of record.) 
3. What are they allowed to do? (Decided at runtime, escalated to a human where it matters, and revocable when it does not go to plan.)

Those three questions are the operating discipline behind the Agentic Enterprise Blueprint.

The Okta blueprint for securing AI agents at scale

Companies like Uber have demonstrated the need to create this type of governance for AI agents.  But not every company has to architect this on its own.

The thread through every layer is the same: Identity is the control plane, authorization is decided at runtime and scoped to the task, the accountable human travels with the request, and the whole thing runs on open standards so it holds across every vendor an agent touches. 

Treating agents as first-class identities on those terms is the right way to secure the agentic enterprise, and Okta for AI Agents makes it a layer you adopt rather than a system you spend a year building.  The architecture in this post is something you adopt, not something you build. 

See how Okta and Auth0 secure AI agents, or talk to our team.