The Blueprint Alliance turns Okta's March framework into a multi-vendor architecture
Okta's release lists the founding members as Amazon Web Services, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz and Zscaler. GE Appliances and World Central Kitchen serve as strategic advisers rather than founding vendors. Compare the Cloud reports that the two advisers are testing the approach against real-world industrial and humanitarian operations respectively. Okta says new members will be added over time.
The alliance builds on earlier work. It evolved and expanded the blueprint for the secure agentic enterprise, which Okta first introduced in March 2026. Ken Yeung at The AI Economy, who covered the press briefing, reports that the March version outlined three questions for security and IT teams to ensure agents don't run amok. The expanded version has four: Where are my agents? What can they do? What are they doing? How do I respond? The fourth question adds incident response and recovery.
Forkast states the nature of the announcement directly: "The Alliance is not shipping a product." The output is a co-authored framework. Okta says it covers governance after agents are deployed and complements existing work on model security and software supply-chain integrity. It applies to employee-facing agents and to customer- and partner-facing agents that cross organizational boundaries.
Okta president and COO Eric Kelleher described the problem as bigger than any one vendor. He told reporters that "the risk of unsecured, ungoverned agents is fundamentally an industry problem, not a problem for one company". The AI Economy also reports that he said the alliance belongs to the industry and is not an Okta product.
Six principles that treat an AI agent like an employee account
The members agreed on six principles. They include treating every agent as a first-class identity, scoping access to the task rather than granting standing access, keeping delegation traceable, monitoring runtime behavior continuously, enabling containment that is instant and reversible, and ensuring governance adapts at the speed AI moves.
The full blueprint explains the reasoning. Enterprise security has long kept human identities, managed with single sign-on and multifactor authentication, separate from machine identities such as service accounts and API keys. According to the document, autonomous agents break that split. They receive a high-level instruction, plan multiple steps, choose tools through the Model Context Protocol (MCP), start sub-agents, and often keep working after the person who delegated the task has logged off. The blueprint says hosted agents should be provisioned, authenticated and deprovisioned as carefully as employees, with no exceptions for pilots or internal tools. Local runtimes on a user's device are handled through endpoint containment rather than directory registration.
The blueprint is open about how far these goals are from current tooling. It calls task-scoped dynamic grants the "aspirational goal." In practice, it recommends pairing short-lived task grants with stable baseline permissions. It also describes end-to-end tracing of delegation across multiple hops as an aspirational target given today's tooling. In other words, two of the six principles are directions of travel, not controls most organizations can deploy fully today.
The document also says controls should match the risk. A read-only productivity assistant does not need the same containment as an agent that can carry out financial transactions. That keeps low-risk deployments from stalling in months of approvals.
Four pillars behind Where Are My Agents and How Do I Respond
Each of the four questions maps to a pillar of the architecture. They all rest on a shared layer of execution context and risk signals, fed by runtime telemetry, logging and observability.
| Question | Pillar | What the blueprint calls for |
|---|---|---|
| Where are my agents? | Discovery, identity, posture management | Catalog internally built, SaaS, third-party and shadow agents; register each as a distinct, verified identity with an accountable human owner or team; continuously scan for vulnerabilities and misconfigurations |
| What can they do? | Access policies and governance | Task-scoped access instead of standing privilege; traceable delegation across sub-agents; least privilege enforced through automated access reviews, separation of duties and joiner-mover-leaver processes for agent scope, owners and model versions |
| What are they doing? | Runtime authorization and resource access | Inline policy enforcement through gateways in the execution path; in-session detection of data leakage, prompt injection and anomalous activity; tracking of downstream targets such as MCP servers, SaaS apps, data stores and payment systems |
| How do I respond? | Response, enforcement and recovery | Targeted containment through rate-limiting, token revocation, session termination or network quarantine; recovery through re-attestation and staged re-enrollment that is deliberate, documented and auditable |
The discovery pillar is the most detailed. For finding unapproved AI, the blueprint lists detection points across cloud infrastructure, network egress, endpoints, browsers, mobile device management (MDM), IoT and OT equipment, and email and collaboration traffic. The last category covers agents that send messages or manage calendars on a user's behalf. The document also proposes treating a governed execution path as a detection surface: if all sanctioned agents run through a central control plane, anything running outside it is flagged as shadow AI.
The blueprint treats supply-chain risk as part of discovery. It warns that MCP and skill registries can themselves carry attacks, because a malicious entry can be pulled in and used automatically. It therefore says every registry-sourced tool or skill should be treated as untrusted and scanned before an agent can call it. It also recommends checking the provenance of agent code, container images and model weights, including SLSA attestations, before production use.
The blueprint adds a legal caution that often goes unmentioned in endpoint- and browser-monitoring discussions. Discovery and monitoring should comply with privacy, employment, labor, works-council and data-protection rules, with transparency, proportionality, data minimization, and controls on retention and access. Organizations in the EU and other regulated markets will need to account for this before turning on browser-session or mail-flow inspection for agents.
Cross-vendor signal sharing over MCP, OCSF, SSF and CAEP is still a work in progress
The alliance's largest promise is interoperability. Founding members say they are building and testing signal sharing across four open standards: the Model Context Protocol, the Open Cybersecurity Schema Framework (OCSF), the Shared Signals Framework (SSF) and the Continuous Access Evaluation Profile (CAEP). The goal is for a threat signal from one vendor's runtime monitor to trigger real-time action in every connected control plane. For example, a detection in a CrowdStrike or Zscaler tool could revoke a token issued elsewhere. That example is an illustration of the stated goal, not a demonstrated integration.
The commitments are phrased in the future tense. Members say they will regularly publish joint interoperability results and reference integrations. The blueprint also names HTTP Message Signatures (RFC 9421) among the standards members plan to validate against. It notes that capabilities vary by vendor and implementation, and that validated results will be published as testing finishes. No such results were part of the September 22 announcement.
Channel Insider argues the effort could still matter to integrators and service providers. It says the alliance's emphasis on signal sharing could provide partners with a more consistent way to integrate identity, security, infrastructure, and application controls as customers deploy AI agents across multiple platforms. That could become increasingly important for providers building AI governance and security services around technology stacks that rarely come from a single vendor.
The urgency figures come from Gartner, cited by Okta. Gartner predicts that by 2028 an average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025. It also finds that only 13% of organizations think they have the right AI agent governance in place. Both figures describe large enterprises and self-reported confidence. They say nothing about any particular organization's agent count.
Okta ships its own implementation alongside the alliance
The alliance launched alongside new Okta products, so the neutral framework and Okta's commercial version arrived the same day. SiliconANGLE reports that Okta used the conference to announce runtime enforcement and a wider kill switch for its Okta for AI Agents platform. Okta had earlier described that platform as the first and best implementation of the blueprint. It became available on April 30, 2026.
The new features follow the pillars closely. According to SiliconANGLE, Shadow AI Agent Discovery for Endpoints looks for unmanaged agents running on those machines. Agent SSO brings Cross App Access, which Okta debuted in June 2025, to all of its single sign-on customers so they can swap non-expiring keys for short-lived tokens tied to an identity. Rules on which agents may call which other agents come through Agent-to-Agent Connections, with each handoff recorded in an auditable chain. Resource Access Certifications review agent connections over time to catch standing or excessive permissions.
Availability varies by feature. Forkast reports that Agent SSO, Agent-to-Agent Connections, and Resource Access Certifications are generally available today, while Agent Gateway and Shadow AI Agent Discovery for Endpoints are planned for Q3, and Configuration Designer and expanded Kill Switch capabilities at the runtime layer are planned for Q4. Okta customers should check each feature's status against their own tenant and licensing before planning around it.
SiliconANGLE describes the threat these products target: an employee connects an AI assistant to everyday tools and unknowingly gives it a path into sensitive systems. If that person later leaves, nothing stops the agent from running on in the background, ungoverned. The blueprint's joiner-mover-leaver principle for agents addresses this same case.
Microsoft Entra's absence shapes how Windows shops should read the alliance
For readers who run on Microsoft 365 and Entra ID, the missing names matter more than the founding list. The AI Economy notes that Microsoft is absent, whose Entra is one of the largest enterprise identity platforms and Okta's most direct competitor. That leaves Okta as the only identity provider among the founding members, in a coalition built on the idea that agent identity needs shared standards. The same outlet reports that model makers such as OpenAI and Anthropic are also absent. Kelleher said this phase is focused on the four enterprise governance questions rather than on the models.
In practice, the alliance's reference integrations, when they are published, will describe how Okta, AWS, Google Cloud, CrowdStrike, Zscaler and the other members exchange signals. An Entra-centered organization cannot assume its identity provider is part of that testing. The standards involved, SSF, CAEP, OCSF and MCP, are open specifications, so the architecture does not formally depend on a particular vendor. Whether any product outside the alliance implements them in a way that interoperates with members' tools is a question for that vendor, not something this announcement answers.
Heterogeneous environments are where the alliance could be most useful. Okta's Ric Smith told Techzine that "our stance has always been that we want to be agnostic to all the tools in the enterprise because most of our customers operate in a heterogeneous environment." For an organization that runs Okta for workforce identity, Salesforce or ServiceNow for workflows, and AWS or Google Cloud for agent hosting, the alliance's roadmap describes most of its stack.
What this means for you
Security and identity teams already deploying agents can use the four-question framework right away as an internal audit tool, with no need to buy anything. Adopting it as an interoperable standard should wait until members publish tested integrations. Organizations that have not deployed agents in production can use the blueprint as a design reference for their first deployments and follow the interoperability results. In procurement conversations, the useful question for any vendor, inside or outside the alliance, is which of SSF, CAEP, OCSF and MCP their product supports today and which it only plans to support.
- Build an inventory of agents that includes internally built agents, SaaS agents, locally installed agent tools and orchestration-platform agents, with a named accountable owner for each one.
- Replace long-lived API keys and borrowed human credentials for agents with short-lived, identity-bound tokens wherever your platform supports them, and include agents in offboarding so they stop when their owner leaves.
- Treat MCP servers and skill registries as untrusted supply-chain inputs, and scan tool definitions before agents can call them.
- Before rolling out endpoint, browser or mail-flow monitoring to find shadow AI, check it against privacy, labor and works-council requirements.
- Rehearse containment by confirming you can revoke an agent's tokens or end its sessions without disrupting unrelated systems, and document how a contained agent gets re-approved.
- Check general-availability status feature by feature for any vendor's "blueprint-aligned" products, because Okta's own additions ship across three quarters.
The Blueprint Alliance currently offers a well-organized vocabulary for a problem most enterprises have not yet solved, backed by a notable list of cloud and security vendors and a published design with its gaps clearly stated. Its practical value depends on the joint interoperability results and reference integrations the founding members have promised to publish. Until they do, the framework is most useful as the audit checklist above, especially for Entra-first organizations that are outside the coalition.