Twelve large enterprise-technology vendors have agreed a common security architecture for artificial-intelligence agents, reflecting the difficulty of controlling software that can move across identity systems, cloud platforms, business applications, data stores, and several suppliers’ infrastructure. The Blueprint Alliance includes Okta, Amazon Web Services, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz, and Zscaler.

The group proposes a multi-vendor reference architecture built around four practical questions: which agents an organisation has, what they are allowed to do, what they are doing while they run, and how access can be removed when an agent behaves unexpectedly or is compromised. GE Appliances and World Central Kitchen are participating as strategic advisers rather than technology vendors.

The coalition reflects a weakness in the current enterprise-AI market because agents are being added independently to SaaS platforms, development tools, data systems, security products, and internally built applications. A single business process may cross several of those environments, making supplier-specific controls incomplete when an agent carries authority from one system into another.

Agreeing an architecture is only a first step, however, because the important question is whether competing products can exchange identity and risk signals reliably enough to enforce it. The alliance says members will test interoperability and publish reference integrations, turning the technical work into the part worth watching.

Agents create an identity problem

Traditional identity systems were designed mainly around people and machine accounts used by applications or infrastructure, whereas agents can act for a person, call another agent, receive temporary authority, and decide dynamically which action to perform. That creates a more complicated chain between the original user and the final transaction.

The alliance argues that every agent should therefore be treated as a distinct identity with an accountable human owner or operational team. Organisations also need to discover agents already operating in their environment, including those built internally, supplied through SaaS platforms, or deployed outside formal IT processes.

Once discovered, access should be tied to the task rather than granted through broad standing privileges, while delegated authority has to remain traceable if one agent hands work to another. Without that lineage, an organisation can lose the connection between the original instruction and an action performed several software steps later.

The control becomes consequential when agents reach systems containing customer information, source code, financial records, or payment functions. A procurement agent may need permission to prepare an order but not approve expenditure above a threshold; a coding agent may inspect a repository without receiving production credentials.

Runtime control sits beside permissions

Permissions alone are insufficient when software has discretion over which action to perform. The blueprint therefore includes monitoring during execution for risks such as anomalous activity, data leakage, prompt injection, or unexpected attempts to reach downstream resources.

It proposes enforcement points in the execution path alongside visibility over SaaS applications, data stores, payment systems, and Model Context Protocol servers. If a risk signal indicates compromise, controls can include rate limiting, token revocation, session termination, and network quarantine.

Those mechanisms borrow from existing zero-trust and identity-security practice, but the object being governed is different. An agent may carry delegated human authority while also interpreting unstructured information and selecting actions that were not completely predetermined when access was granted.

Recovery also becomes a security process rather than a simple restart. The alliance proposes re-attestation and staged re-enrolment so that an agent’s access is restored deliberately after an incident instead of returning automatically when a transient alert disappears.

No single vendor owns the agent stack

The alliance’s membership is notable because several participants compete directly with one another. AWS and Google Cloud run rival infrastructure platforms, security vendors overlap across several markets, and Salesforce and ServiceNow are both pushing agentic software into enterprise workflows.

Yet an agent built in one platform may authenticate through Okta, retrieve information from Databricks, call another SaaS application, run in a hyperscale cloud, and generate security signals handled by several different tools. An architecture working only inside one supplier’s product family leaves gaps at those boundaries.

The alliance says members will therefore test interoperability using existing standards including Model Context Protocol, Open Cybersecurity Schema Framework, Shared Signals Framework, and Continuous Access Evaluation Profile. If that work succeeds, suspicious behaviour detected by one product could trigger access changes elsewhere without an administrator manually stitching the incident together.

A vendor coalition is not an independent standards body, and commercial incentives remain, so reference diagrams are easier to produce than genuinely compatible implementations. The credibility of the initiative will depend on whether those interoperability tests expose enough shared behaviour to work across competitors’ systems.

Agent sprawl moves ahead of governance

Enterprise SaaS already created problems around shadow applications and inaccurate access records, and agents can multiply more quickly because employees and developers may create them inside software the organisation already owns. That can produce agents whose existence or privileges are not centrally understood.

The problem becomes more serious once those systems possess credentials and can act through APIs. Security teams need an inventory before sophisticated autonomous defences become useful because least privilege, ownership, monitoring, and incident response cannot be applied consistently to agents nobody knows exist.

That places agent security closer to conventional enterprise architecture than to a completely new discipline. Identity, access control, logging, posture management, monitoring, containment, and recovery all exist already; the challenge is adapting them to software that exercises greater discretion while it operates.

The Blueprint Alliance gives enterprise buyers a useful indication that major suppliers recognise the cross-vendor problem, but the next test is technical rather than rhetorical. If identity and security signals can travel reliably between competing products, agent governance may develop into a shared control plane; if not, organisations risk building another collection of dashboards around an already fragmented software estate.