8 Questions a CISO Should Ask Every AI Agent Security Vendor

Most AI agents in production today authenticate to their tools with a static key. The key sits in an environment variable, it never expires, and it is the same key whether the agent is summarizing a support ticket or refunding a customer. This is not secure.

Gartner predicts that more than half of successful cyberattacks on AI agents will exploit access control weaknesses and prompt injections by 2029. In a Cloud Security Alliance survey published this year, only 18 percent of respondents said they were highly confident their IAM systems could manage agent identities.

Those are forecasts, but the incidents are not. On 09/09/2026 Anthropic disclosed four cases in which its models reached real third-party systems during cybersecurity evaluations that a misconfiguration had left connected to the internet. In one, the model published a malicious package, and in Anthropic's words, "One vendor's scanner leaked its access credentials to the model while installing the package, which the model then used to access the vendor's live database." Five days earlier, researchers at the Nightingale Collective documented roughly 18,000 posts on a disused German wiki written by autonomous agents that were "supposed to have the ability to read the internet but not to write on it", and that used it to pool answers and share ways around their own restrictions.

The point: a permission that exists only as an instruction to a model is not a permission. It has to be something the model does not get to ignore.

The industry knows this is a problem. Every vendor with an agent story now has a security story attached to it. However, each vendor covers one part of the problem and leaves the others to someone else. This is a significant issue, since all these security vendors are both right and wrong at the same time.

This post covers the categories of agent security infrastructure, their limitations, and their strengths, so you can ask the right questions and not leave gaping security holes that can be used to compromise your production agents.

What "secure" has to mean for an agent

Let's start with what "secure" has to mean for an agent. An agent that can call tools needs three things from its infrastructure. All are required for the best level of security.

• It needs an identity it can prove, so the thing on the other end of the call (other agent, MCP server, app, etc.) knows which agent or workload is asking.
• It needs a policy that says which tools that identity may discover and call, starting from "no access to anything by default".
• It needs every hop between it and the tool to be authenticated, so the identity and the policy cannot be bypassed by whoever holds a token.

These are not independent features. A policy keyed on a bearer token is a policy about whoever stole the token. An identity with no policy attached is a name in a log. Having an identity and a policy mean nothing the moment a call escapes the pipeline and skips the check. Complete agent security only exists when all three capabilities are present together, and that place has to be the runtime the agent is bound to.

Ask the vendor: "Which of these three do you provide yourself: an identity attested by the infrastructure, a per-tool policy that starts at deny, and mutual authentication on every hop? Which do you leave to someone else?"

Agent security categories

There are four categories of agent security infrastructure:

• MCP and AI gateways
• Identity vendors
• Cloud agent platforms
• Durable execution runtimes

The MCP gateways: policy on a bearer token

Gateways are where most of the MCP security market is currently. They sit between agents and MCP servers. There are many vendors emerging offering gateways, since they offer a fast solution to solving policy access. The good ones now do per-tool allow-lists with filtered discovery, and this is real progress. Kong's Tool ACLs filter the tool list so clients "never even know about restricted tools". Solo's agentgateway does the same.

However, even the best ones have an inherent architectural flaw. The differentiator is what the gateway thinks a caller is.

• Kong maps "authenticated principals" to "Kong consumers and consumer groups".
• Solo's agentgateway evaluates JWT claims, and its documentation states the default plainly: "By default, all tool access is allowed." That default is the opposite of the one a CISO wants.
• Cloudflare's WriteGuard announcement from 05/08/2026 describes agents that "operate with that employee's permissions" and says "We kept that model instead of introducing standalone agent accounts."

In every case the caller is a token or a human session, and the policy applies to the traffic that chose to go through the proxy. An agent with a direct route to the MCP server, or a stolen token, is outside the model.

There is a second cost to adding a proxy. IBM's ContextForge MCP Gateway has published 19 security advisories in 2026, five of them Critical. One, CVE-2026-53709 on 15/06/2026 at CVSS 9.8, was a hardcoded default signing key shipped in the repository, letting "any party who can read the public repository" forge a token the gateway "accepts as an authenticated platform administrator without ever sending credentials". The box you install to secure your agents is another box in the path that can be compromised.

The protocol does not solve this either. The MCP specification, revision 2026-07-28, provides "authorization capabilities at the transport level", states that "Authorization is OPTIONAL for MCP implementations", and puts authorization server behaviour "beyond the scope of this specification". Per-tool policy is something the layer above the protocol has to supply.

We wrote about this in more depth in MCP Gateways Aren't Enough: AI Agents Need Identity, Authorization, and Proof. The summary here: a gateway secures a path, it cannot secure a workload it does not run. It is not a runtime.

Ask the vendor: "If my agent calls the MCP server directly instead of through your proxy, what stops it? And where does the upstream credential live?" A good answer names an enforcement point the agent cannot route around. A bad answer is "configure your network so all traffic goes through us".

The identity vendors: they stop at the token

Okta's Cross App Access is now the enterprise pattern for MCP authorization, and it is good engineering. It is built on RFC 8693 (an OAuth standard for swapping one token for another) and RFC 7523 (an OAuth standard for presenting a signed JWT to obtain an access token), and it "replaces the user's manual approval step with a token exchange to enable an application to request an access token for a resource server without any user interaction". Note the granularity: an application gets a token for a resource server. Which tools on that server the agent may call is not the identity provider's problem.

Aembit has the sharpest framing in this group. Its Identiverse write-up says "visibility is not the same as enforcement" and that "The harder problem is runtime authorization: deciding, at the moment of access, whether a specific agent acting on behalf of a specific user should be allowed to use a specific tool, take a specific action, or reach a specific system." We agree. Aembit enforces that decision from an identity gateway that sits beside your infrastructure. It does not run the agent, so it cannot bind the decision to the agent's execution, and the post never claims to.

The summary here: an identity provider can issue a token, but it does not secure the agent workload, and typically identity vendors do not have tool access policies.

Ask the vendor: "After you issue the token, who decides which tools on that server the agent may call, and what happens when that token is stolen?" A good answer has a per-tool policy keyed on something the thief does not get. A bad answer is "the resource server handles that".

The durable execution vendors: a runtime without an identity

A particular group of companies provides durable execution runtimes for agents. Temporal, Restate, and Inngest solve a real problem: agents that crash halfway through a task and start over. But their security model is the security model of a SaaS.

Temporal Cloud authenticates with "namespace-specific X.509 certificates for mutual TLS authentication" or "namespace-scoped API keys". There is no identity per agent, no policy per tool, and no MCP policy access. The runtime knows which namespace a worker belongs to. It does not know which agent is calling which tool, and it has no opinion about whether that should be allowed.

Restate documents client-side encryption of "invocation inputs and outputs, step results, and state", which is confidentiality, and reserves its cryptographic signing for request identity, "to cryptographically verify that requests have come from a particular Restate instance". The execution history is protected from being read, not from being altered.

LangGraph checkpointers "persist a thread's graph state as checkpoints" scoped to "A single thread", while its Agent Server "Uses LangSmith API keys by default" and self-hosted deployments get "No default authentication". That is durable execution with no workload identity underneath it.

Ask the vendor: "When an agent does something it should not, mid-workflow, what does your runtime know about which agent called which tool, and could it have refused?" A good answer names the identity and the policy. A bad answer is "we have audit logs".

The clouds: identity that lives in one cloud

Let's now look at the three agent platforms provided by Microsoft Azure, AWS, and GCP.

Microsoft Entra Agent ID gives each agent a directory identity, and Microsoft's documentation is candid about where that stops. The Conditional Access documentation states: "if an agent accesses resources using an API key, it bypasses the Microsoft Entra ID authentication and token issuance pipeline entirely and Conditional Access policies won't apply to them." The Foundry agent identity documentation adds that "all unpublished or in-development agents within the same project share a common identity", tells you to "treat the shared project identity as a broader blast radius", and lists as a limitation that "only some tools currently support agent identity authentication". With Microsoft the whole model is Entra-issued bearer tokens. There is no workload certificate and no mutual TLS between agents and tools.

AWS Bedrock AgentCore has the strongest tool-level policy engine of the three. Its Cedar policies are deny by default: the documentation says "all actions are denied by default" and that the engine "enforces a default deny posture". But the same page opens by scoping it: "Policy in AgentCore uses Cedar policies to control access to AgentCore Gateway tools." The policy lives in the gateway, so it governs calls that go through the gateway. And the identity underneath it is not cryptographic. AgentCore Identity integrates "through Sigv4, standardized OAuth 2.0 flows, and API keys". Those are credentials an agent holds, not an identity attested by the infrastructure it runs on.

Google is the closest to the right architecture. Agent Identity is built on SPIFFE, and "each X.509 certificate is valid for 24 hours, and Google Cloud automatically keeps it current". That is workload identity done properly. The same page lists the services that support it: the Gemini Enterprise Agent Platform Runtime and Gemini Enterprise, nothing else. Google's own status post from 06/05/2026 has Agent Identity generally available on the Agent Runtime, while "Agent Identity for Gemini Enterprise Agent Platform is in preview", "Agent Identity Auth Manager is in preview", and the per-tool "Unified Access Policy (UAP) for Agent Identity is coming soon".

Three cloud vendors with a single shared property: the identity only exists inside that vendor's cloud, and in two of the three cases it is a token rather than an attested workload. If your agents run in your own cluster, or in a different cloud, none of these follows them there.

Ask the vendor: "Does the agent identity still work when the agent runs in my own cluster or in another cloud? Which parts of your identity and policy story are generally available today, and which are preview?"

The gaps, side by side

Put the groups side by side and you see the gaps in each:

• Gateways have policies with no identity.
• Identity vendors have identity with no runtime.
• Durable execution runtimes have execution with neither identity nor per-tool policy.
• Major cloud vendors come closest, with parts still in preview, and all of it inside their own cloud.

How Diagrid Catalyst closes the gap

Catalyst is the runtime: it issues the identity, enforces the policy, and terminates the mTLS itself. It also provides durable execution. And it goes further, producing a signed, verifiable record of the steps an agent took. This is what we call Agentic Durable Execution.

Let's look at each in turn.

Issuing identities

In Catalyst, every application, agent, and MCP server connection runs under a SPIFFE application identity with a certificate issued and rotated by the platform. This is fully transparent and managed for you.

The identity is an open standard, and it follows the workload: the same model covers an agent on a developer's laptop, a service in a private Catalyst region running in your own cluster, and a connection to an external MCP server. Outbound, that identity is what authenticates to the upstream. Catalyst presents an audience-scoped JWT minted from the workload identity that expires within 24 hours, and the operator of the upstream server verifies it with ordinary OIDC discovery against a public issuer that every Catalyst region exposes, pinning the exact SPIFFE ID they expect. There is no client secret anywhere in that chain.

This is the pattern NIST's National Cybersecurity Center of Excellence is now studying: its concept paper from February 2026 lists MCP, OAuth 2.0 and 2.1, OIDC, and SPIFFE/SPIRE among the standards under consideration, and describes SPIFFE/SPIRE as "one way in which agent workloads could be identified and authenticated".

Because the identity is a standard one, it federates with the clouds directly. Importantly, this means Catalyst integrates with any system that uses SPIFFE, in particular the major clouds. This means you can federate Catalyst, which can be deployed anywhere, with Azure, AWS and GCP and have zero client secrets in your code when accessing cloud services.

MCP tool access with policies

Catalyst has a catalogue of MCP servers, or you can register your own. With Catalyst you can govern any MCP server your agents reach.

Every MCP server registered in Catalyst starts deny-all for all agents and workloads. No agent can discover a single tool until someone (the platform team) grants it, and the grant is a resource you can put in version control. Here is a typical example:

apiVersion: cra.diagrid.io/v1beta1
kind: MCPServerAccessPolicy
metadata:
  name: mcp-server
spec:
  mcpServerRef: mcp-server
  rules:
    - callers:
        - appID: analyst-agent
      grants:
        - capability: tools
          names: ["query", "search"]

The workload named analyst-agent may call query and search on this server: nothing else, and nobody else. When the analyst team needs one more tool next week, the change is one more name in that list, not a redeploy.

When the agent lists tools it sees those two; a tool it is not granted is absent from the list, not marked forbidden, so the model can never be prompted into calling it. A call outside the grant is refused inside the platform before the upstream is contacted.

An agent with no grant at all cannot even see that the server exists. Importantly, the difference from an MCP gateway is where this runs: inside the runtime, on both ends of the call. The agent's connection to Catalyst hides the servers it is not granted, and the MCP server's connection checks every tool call against the caller identity that the agent's sidecar proved over mTLS, not a token the agent presented. There is no unproxied path to skip it. Inside Catalyst every call is identity-checked and policy-checked, and the agent never holds the upstream credential it would need to go around the runtime.

Secure communication on all hops with mTLS

Every hop between Catalyst runtimes (agents, MCP servers, apps) runs over mutual TLS with the workload certificates. Your code reaches its own Catalyst runtime with a per-application API token, and everything past that point is certificate-authenticated.

That is what makes the policy trustworthy: the caller identity it evaluates was proven in a handshake in the runtime, not asserted by the agent. It is also what keeps upstream credentials out of agents. Whatever a connection uses to authenticate to its upstream is presented after the policy check, on the far side of the mTLS boundary, and the agent is never party to it. With SPIFFE JWT authentication there is no stored credential at all. Catalyst mints a token from the connection's own identity, valid for at most 24 hours and scoped to that one upstream's audience, and presents it on the connection's behalf. The agent never sees the token, and an intercepted one would name the connection rather than the agent, expire on its own, and fail the audience check at any other server.

Where an upstream still requires an API key or client secret, that credential is attached to the connection and injected at the same point. The agent's process, environment, prompts, and logs never contain it. A compromised agent can still attempt calls, and every attempt is identity-stamped and policy-checked, but there is nothing inside the agent worth stealing.

Tamper proofing with attestation

Catalyst is also the durable runtime the agent executes in: an agent that crashes resumes from the point of failure instead of starting over. Catalyst 2.0 can sign that execution history with the same workload identities, and you turn it on when you create the project. Every vendor above produces audit logs, and a log is a record that someone with write access can change. A tamper-evident signed history is a record that anyone holding the region's trust anchor can verify, and none of the products in this post ship one.

What Catalyst does not fix

Identity, policy, and mTLS bound what an agent can reach and prove who did what. However, they do not make the model trustworthy. A manipulated agent can misuse the tools it is legitimately granted, which is the argument for granting as few as possible to limit blast radius on a compromised agent. This is a very real and open security issue.

Anthropic's own figures are the argument for narrow grants. In a capture-the-flag cyber evaluation designed to elicit exactly this behaviour, across 150 runs, its models took a severely harmful action in between 31 and 82 percent of runs depending on the version. The newest model was the best of the group at staying inside its sandbox and still took a severely harmful action in a third of runs. No infrastructure makes a model trustworthy. What infrastructure can do is keep the set of things a misbehaving model can reach small, and make what it did afterwards provable.

In addition, the upstream MCP server's own code is still its operator's responsibility.

Catalyst shrinks the blast radius and produces a verifiable record of what happened. It does not eliminate prompt injection. What it does do is solve end-to-end security from agent through to resources used, and provide proof of exactly what happened. You can think of this as trusted execution in software for applications and agents, or what we call agentic durable execution.

The CISO checklist

Summary

The vendors in this post are not wrong about the problems they solve; they are each solving the part of it that their product can reach. An identity provider can issue a token, a gateway can filter a path, a workflow engine can restart a task. None of them can make an agent's identity, its permissions, and its execution the same fact, because none of them run the agent. This is what Catalyst does.

Catalyst works with the agent framework you already use: LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, OpenAI Agents SDK, Claude Managed Agents, CrewAI, Pydantic AI, Spring AI, or your own code.

Start a free Catalyst project and register an MCP server, or talk to a Catalyst expert about what your agents are holding in their environment variables today.