Blueprint Alliance: A Shared Architecture for AI Agents

From an Okta blueprint to a shared architecture

#

In March, I wrote about Okta’s Blueprint for the Secure Agentic Enterprise. Its questions were deliberately practical: Where are my agents? What can they connect to? What can they do? An identity for each agent, an accountable owner and governed connections were the starting point. They still are. But an agent rarely lives in one vendor’s environment. It may be built in a cloud platform, call tools through MCP, retrieve data from another provider, invoke a SaaS application and hand work to a second agent. One control plane cannot see every part of that journey on its own.

On 22 September 2026, Okta and eleven other founding members announced the Blueprint Alliance. AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler joined Okta across identity, AI, data, applications, infrastructure and cybersecurity. GE Appliances and World Central Kitchen are strategic advisors. The Alliance has published an expanded, multi-vendor blueprint and the Governing Agentic Execution white paper.¹²

For me, the interesting news is the architectural shift. The original Okta blueprint described an identity-centered way to govern agents. The Alliance asks how different systems can cooperate when an agent crosses their boundaries.

Its four questions now read: Where are my agents? What can they do? What are they doing? How do I respond?

That progression adds continuous observation and coordinated response to discovery and access. It is a reference architecture and an industry commitment to test interoperability, rather than a claim that every integration is already available.¹

Blueprint Alliance graphic from the Okta announcement.

Why the vendor boundary matters

#

Imagine a support agent receiving a customer request. It queries a knowledge base, reads a record in a data platform, opens a ticket in ServiceNow and asks a specialist agent to check an exception. Its useful work spans several identities, policies, networks and logs. If only the first connection is governed, the next handoff may lose the original user’s context. If only the last tool is monitored, the responder may know what happened without knowing who authorized it.

The white paper’s six principles address this chain: treat agents as first-class identities; scope access to the task; preserve delegation; monitor runtime behavior; make containment fast and reversible; and adapt governance as agents change.²

It also states important limits. Fully task-scoped grants and end-to-end multi-hop delegation are target states that current implementations may not yet achieve. A practical design may combine short-lived task grants with constrained baseline permissions. Local runtimes and ephemeral sub-agents inheriting a parent’s scope can be governed through endpoint containment and delegation controls rather than separate directory entries. A gateway alone cannot make model output trustworthy.

The members are building and testing interoperability using MCP, OCSF, SSF, CAEP and, as the white paper adds, HTTP Message Signatures. Reference integrations and test results are planned for publication.¹²

Four questions, one agent lifecycle

#

1. Where are my agents?

#

You cannot review access for an agent you do not know exists. Inventory must cover agents built by your developers, agents embedded in purchased software and employee-created agents. Registration should capture a distinct agent identity, the human or team accountable for it, its purpose, environment, owner, lifecycle status and connections. A service account or API key may still be involved, but neither is an adequate substitute for the agent’s own identity.

The white paper connects discovery to security posture: examine software provenance, vulnerabilities, configurations and even MCP tool or skill definitions before treating an imported agent as trusted.² It also says browser and endpoint discovery should respect applicable privacy, employment and data-protection requirements. I explored the relationship between agent governance and regulatory requirements in my EU AI Act article. Okta’s Oktane 2026 announcement describes registration, imports from AWS Bedrock and Salesforce Agentforce, and browser discovery. Endpoint discovery has a separate planned availability date.³

Discovery is only the first pass. An inventory goes stale as soon as teams clone an agent, change its model, add a tool or move it between environments. The practical test is whether each new connection can be reconciled to an owned, registered identity, and whether orphaned agents are found when their human owner changes role or leaves.

2. What can they do?

#

The answer is more precise than a list of reachable applications. An agent may be allowed to read a case, but not change a payment method; to call one specialist agent, but not delegate further; to act for a particular user, but only within that user’s own entitlement. The permission boundary must travel with the task, including downstream calls.

This is where Cross App Access (XAA) and token-based delegation become concrete. In my access patterns overview and technical deep dive, I compare XAA with Secure Token Service, pre-shared keys and service accounts. The key question is whether the resource can verify an authorized agent and retain the human context when the agent acts on someone’s behalf. An OAuth token should be narrow in audience, scope and lifetime; the resource must still enforce its own authorization rules. A valid token alone does not authorize every tool action.

The white paper also calls for separation of duties, access review and lifecycle management.² For sub-agents, the effective permission should be the intersection of their own scope and that of the delegating user or agent; delegation depth and breadth need limits. Intent-based policy is an advanced layer, and the paper cautions against trusting the literal prompt as the sole signal of intent.² At Oktane 2026, Okta announced the availability of agent-to-agent connections and Resource Access Certifications. Configuration Designer is also coming soon; it will visually map agent-to-resource connections so each handoff can be governed, scoped and audited.³

Among Okta’s recent announcements, Agent SSO brings Cross App Access into core Okta SSO for compatible agents. It has been generally available since August 2026.⁴ It illustrates one way to bring agent identity into an existing access model; I will explore the product and its technical flow in a separate article.

3. What are they doing?

#

An access review tells you what an agent could do. Runtime telemetry tells you what it did. An investigation needs the agent identity, human principal where applicable, target resource, tool and operation, policy decision, timestamp, delegation chain and a correlation identifier. It also needs enough context to distinguish a normal workflow from a surprising sequence, while avoiding unnecessary logging of sensitive prompts or data.

The white paper distinguishes AI/LLM, MCP, security, agent and API gateways: each observes a different boundary, and the downstream API must still authorize its own requests.² It also calls for runtime isolation, prompt-injection inspection, data-loss prevention, purpose-aware data use and tracing. Logs should be captured at the execution boundary and redact secrets and personal data. Correlated risk signals are the connective layer, rather than a single gateway that magically sees everything.

Another recent announcement, Agent Gateway, places identity and policy controls in the tool-call path.⁵ It is one example of how a vendor can contribute to the Alliance’s runtime pillar.

4. How do I respond?

#

When an agent begins a suspicious sequence, a responder needs more than an alert. They need a proportional way to throttle calls, revoke tokens or sessions, isolate the affected runtime, preserve evidence and restore service after re-attestation. The white paper favors the least disruptive effective response; terminating a process can destroy useful in-memory evidence. It warns that a “kill switch” is credible only if the hosting runtime can actually pause or isolate the targeted agent.²

A risk signal from one monitor should identify the agent and affected session clearly enough for another control plane to act and send back confirmation. SSF and CAEP are relevant building blocks, but the announcement is not proof that all twelve vendors already share live containment workflows.¹²

Okta currently describes agent deactivation through its admin console as blocking new sessions. At Oktane it also announced a planned expansion of the Kill Switch to Agent Gateway, intended to revoke active tokens and stop in-flight sessions for agents connected through the gateway.³ That distinction matters in an incident runbook: blocking a future login and terminating existing access are different controls.

The four-pillar reference architecture from the Blueprint Alliance website. The downloadable architecture PDF offers a closer view.

What an enterprise should test first

#

The white paper recommends a useful sequence: establish normalized telemetry first; discover and register agents; layer authorization; instrument runtime before automating response; then pressure-test containment.² I would apply that sequence to one agent crossing two systems, with a task whose permissions can be kept narrow. Then walk through the four questions end to end:

1. Inventory and ownership: Can you identify the agent, its environment, model or version, owner and all intended resource connections? What happens to that identity if its owner leaves?
2. Authorization and delegation: Can the agent prove who it is? If it acts for a user, can each downstream resource preserve that user context and enforce a narrower scope than the user’s full entitlement?
3. Runtime evidence: Can your logs connect the user request, agent identity, tool call, policy decision and target resource? Can security teams spot a tool sequence outside the approved task?
4. Response and recovery: Can you block a new connection, revoke an active one, preserve evidence and re-enable the agent through a documented review?

Use a deliberately failed test as well: ask the agent to call a tool outside its allowed scope. The result should be a denied operation and an intelligible audit event. A second test can change the agent’s owner or disable its identity. These small exercises expose the seams between identity, gateways, applications and incident response far better than a slide showing green checkmarks.

Okta’s own digital workforce lessons give this a useful operational dimension. Jenna Cline describes registering agents, including Okta’s internal digital coworker Dex, in Universal Directory and constraining their access in relation to the human they serve. She also describes choosing fewer, more capable agents over uncontrolled proliferation and limiting the tools visible to an agent.⁶ That last choice can reduce both exposure and the amount of tool context sent to a model, but it still needs measured testing in each workflow.

The white paper’s five “Blueprint in Action” scenarios are explicitly composite illustrations.² Its runtime architecture also complements model and supply-chain security.

What I will watch next

#

The Blueprint Alliance site and its white paper are useful starting points for the shared architecture. The next milestone I want to see is published, reproducible interoperability: an agent registered in one system, a delegated call into another, a risk signal from a third and a targeted response with a complete audit trail. The Alliance plans to publish reference integrations and test results.¹

The practical lesson is already clear. AI agent security is a lifecycle problem. Identity establishes who the agent is; authorization limits what it may do; runtime signals show what it is doing; response decides what happens when it deviates. The Alliance gives vendors a common set of questions to answer together. Okta for AI Agents (O4AA) contributes to all four answers through agent discovery and registration, governed connections and access, visibility into activity, and response controls such as deactivation and containment. Agent SSO and Agent Gateway are two recent announcements within this broader effort.³

If you are building an agent today, which of the four questions is hardest to answer across your own stack? I would be interested to hear where your identity and security tools still lose the thread. Tell me in the comments or on LinkedIn.

Sources and further reading

#

• Blueprint Alliance announcement, Alliance website and white paper
• Okta Agent SSO announcement, Agent Gateway technical overview and Oktane 2026 availability details
• Okta’s digital workforce lessons
• Okta Cross App Access documentation and OAuth Cross-App Access overview
• My earlier posts: the original blueprint, AI agent access patterns, the technical access deep dive and AI agent compliance considerations