Why Security Leaders Need to Be in the Agent Conversation

Enterprises are moving AI agents out of pilots and into production. This series has already covered why agents fail in production without infrastructure, how durable execution keeps them running even after failures, and what they cost to operate at scale. Governing what those agents are allowed to touch is the next gap security teams inherit.

An agent in production calls APIs, queries databases, invokes tools, and spins up other agents. Most of them do it with a shared API key pulled from an environment variable, with no record of which agent made which call. That is the workload identity problem, which most security teams have not yet been asked to solve.

The Workload Identity Problem

Security teams are not always late to the agent conversation. In many enterprises, SecOps is the gatekeeper for production, setting the bar that every deployment must clear. What is new is the subject they are being asked to govern. Frameworks get chosen by data science and runtimes by platform engineering. The agent framework, whether LangGraph, CrewAI, Microsoft Agent Framework, or Google ADK, defines how the agent reasons and calls tools, but it does not determine what the agent is allowed to access. Agent identity is a security concern, and it arrives in a form most teams have not had to govern before.

The failure mode is familiar to anyone who lived through the early microservices era. Workloads are often authenticated with a shared secret or with an identity that stops at the process or container boundary rather than at the workload itself. A pod-level identity in Kubernetes, for example, is carried by every container in the pod, so AKS-managed identities and similar schemes could not distinguish one workload from another within that boundary. Teams leaned on static secrets and coarse identities until the industry moved to per-workload identity, SPIFFE, mutual TLS, and trust federation. Agents raise the stakes because an LLM reasoning over a vague instruction can generate a call that no developer has written.

A shared API key is a master key handed to every worker in the building. It opens the doors, but it does not record who walked through, and one lost copy exposes everything. What a production system needs is closer to an employee badge, an identity issued to one worker and verifiable at any door. The badge alone does not decide which doors the worker may open; that is a separate control, but without it, there is no way to ask the question.

The consequences manifest rapidly through credential sprawl, lack of call provenance, and privilege escalation when an agent uses an unintended tool. During incident reviews, there is no verifiable record of which agent used which tool, in what context, or under whose authority.

Consider an agent with access to a customer database. The credential is valid, and the route is permitted, so every perimeter check passes. Mid-workflow, the LLM interprets an ambiguous instruction and calls a customer-record deletion tool with a broad filter. Identity is only half the problem here. Knowing who is calling is authentication, and the shared key barely establishes even that. Deciding what that caller may do is authorization, and a credential that proves possession says nothing about it. Identity is the necessary first step, and the authorization control that acts on it is the subject of the next section.

Every Agent Gets an App ID, the Data Plane Gets SPIFFE Identity

Diagrid Catalyst closes this gap by binding every workload to an App ID. An App ID is an application's identity within a Catalyst project, allowing security teams to set boundaries between workloads and attach policies to them. Each application or agent authenticates to Catalyst with an App ID API token over TLS.

SPIFFE, the Secure Production Identity Framework for Everyone, is an open standard that provides software workloads with a verifiable identity. Instead of a shared password or API key, each workload gets a short-lived credential, an SVID, that serves as its identity and can be verified by whatever it talks to. The microservices world adopted it so that services could authenticate one another without static secrets, and the same model now extends to agents.

The application itself does not possess a SPIFFE identity, which is crucial for security engineers reviewing the documentation. Within the Catalyst data plane, the Dapr sidecar/proxy representing an App ID is assigned a short-lived SPIFFE-based X.509 SVID and uses mutual TLS to authenticate communication among data-plane components. These identities are issued and rotated automatically, enabling the workload layer to authenticate with verifiable certificates rather than long-lived keys that reveal nothing about their bearer.

This extends to the tool layer, where the majority of agent risk resides. Applications, agents, and MCP servers all carry App IDs, so an MCP server is an identified workload in its own right, not just a target. That identity works in both directions. It controls who may call the server and lets the server authenticate to the backing infrastructure via federated identity, enabling access to a database without a shared connection secret. As a caller-facing control, each MCP server is protected by per-caller, per-tool access policies. Callers are identified by App ID, tools are granted or denied by name, and a server starts deny-all, so an unauthorized call is rejected with a 403 before it reaches the upstream server.

Enterprises gain the ability to identify callers directly, rather than relying on just API keys. Because the target resource has its own App ID and access policy, it decides which callers it accepts. When an agent invokes a payment tool, that tool's policy evaluates the caller's App ID and allows or denies the call, rather than accepting an anonymous process that happens to hold a secret.

Security teams can implement this by assigning specific access rights: providing a research agent with a read-only MCP tool on a knowledge base, granting a finance agent limited ledger tools, and restricting each App ID from accessing others' tools. These permissions are managed per App ID rather than via shared keys. Revoking an agent means removing its App ID from the access policies that grant it access, thereby cutting its access without touching a key that other workloads share.

A Catalyst access policy is a short YAML manifest that the data plane enforces natively. It names the target workload, lists the App IDs allowed to call it, and, for an MCP server, the specific tools each caller may invoke. An empty rule set denies everything, so access is additive by design. To grant the finance agent read access to the ledger MCP server, a security engineer adds that App ID and the read tool to the server's policy and applies it. The change takes effect at runtime, with no agent redeploy. The AI agent identity webinar recap walks through a live example.

Enforcement at the Data Plane

Identity is only half the control. The other half is deciding what each identity is allowed to do, and where that decision is enforced.

Catalyst enforces authentication and authorization in the data plane - the runtime layer that sits between an agent's application code and the network. Checks run there rather than inside the agent's own logic, so the agent cannot bypass them. At the Catalyst level, the model is simple. An App ID can call a defined set of APIs, and the access policies attached to that App ID decide which of those calls are allowed. A policy is evaluated before the request reaches the target API, component, or tool, and a failed check is rejected before it touches the backing store. An agent can be allowed to call a read-only MCP tool and denied a write or delete tool, and no prompt, however cleverly constructed, changes what the data plane permits.

Access rules are managed as Catalyst access policies rather than baked into agent code. When security updates a policy, the update takes effect at runtime without agent redeployment. A CISO approves the platform once and keeps control without re-reviewing every change a development team ships, which is the difference between security as a gate and security as a bottleneck.

Enforcing rules outside application code serves a specific purpose. Controls written into an agent's own logic are only as trustworthy as the code around them, and a non-deterministic agent is the least reliable place to put a security boundary. Moving enforcement to the data plane places the boundary beyond the agent's reach.

App IDs for Agents - Without Replacing Enterprise Identity

The concern for a security leader is that this means another identity silo to run alongside the ones they already operate. Catalyst is built to avoid exactly that.

Catalyst does not replace enterprise identity systems. Human access to the control plane is governed by enterprise access controls, including SAML single sign-on on Enterprise plans, while runtime workload identity is handled by App IDs, Catalyst policies, and SPIFFE-backed identities within the data plane. Automation uses API keys scoped to a project.

The key point is that agents are a new subject type, not a new directory. Human identities remain with their enterprise providers. Runtime access is governed by the agent's App ID, the logical identity Catalyst assigns, backed at runtime by a short-lived SPIFFE SVID that the managed data-plane sidecar carries, and by the access policies attached to that App ID. Catalyst adds this layer of agent identity and policy without replacing the identity systems a security team already runs or requiring a migration.

Verifiable Execution, from Approval to Payout

The prior post in this series covered durable execution, which keeps a workflow running across failure. Verifiable execution is the second half of the same story: the ability to prove what that workflow actually did. Catalyst is built around the combination rather than either half alone, so a workflow both survives a crash and leaves a record an auditor can trust.

Durable execution carries a subtle exposure that the durability itself creates. A Dapr workflow is its history. The engine replays a recorded event log to decide each step, and that log lives in a state store. Anyone who can write to that store can rewrite the decisions, through leaked database credentials, an old backup, a shared-database neighbor, or a compromised component. Flip an approval, change an amount, replay a "payment sent" event, and the engine believes it.

The risk is not hypothetical. In February 2025, roughly 1.5 billion dollars drained from Bybit in the largest crypto heist on record. The signers did everything right, reviewing the transaction and approving it. The screen lied. Malicious code had swapped the destination after what they saw, so they authorized one thing while the system recorded and executed another. Bybit was a signing-interface compromise rather than a tampered execution log, but the failure mode that matters here is a system faithfully carrying out something humans never approved, and durable execution on its own would have replayed that record without question.

Verifiable execution closes the gap with three mechanisms. History signing signs every event as it is written, using the sidecar's SPIFFE identity, and chains each signature to the previous one, so any edit breaks the chain and the workflow fails closed, rather than trusting an altered log. History propagation carries the signed history and the signer certificates across workflow, service, and application boundaries, so a downstream service can verify events it did not produce. Attestation hands the verified context to the next step so it can authorize based on it.

That last move is the payoff. Because the propagated history is verified, a downstream step can make its authorization decision from it. An orders service signs its history; a payments service verifies that history and releases a payout only if an approved event exists from an authorized approver within that approver's limit. The rule is a single declarative policy, and the trust comes from the signature rather than from a claim in the request. An approval from unauthorized personnel or an amount exceeding the limit is rejected, and editing a row directly in the database results in a verification failure, causing the row to be closed. These are opt-in capabilities wired into the workflow and tool boundary, not a property of ordinary observability, and teams should plan the root CA lifecycle before enabling history signing.

For teams in regulated sectors, this is not optional. Financial services and healthcare organizations use Diagrid to attest to what each agent did and when, because their auditors and regulators require a provable record, not one reconstructed after the fact. When an agent approves a transaction or touches patient data, a signed, independently verifiable history is the evidence a compliance review and a legal team can stand behind.

Consider an agentic payment flow with two steps, a fraud-check step and a payment step. The requirement is simple to state but hard to enforce - the agent may invoke the payment tool only if the fraud-check step actually ran and passed. Under shared credentials, there is no way for the payment tool to know whether the prior step happened, so it just trusts the caller.

These capabilities, verifiable execution, were introduced in Dapr 1.18. They are opt-in, wired into the workflow and tool boundary rather than a property of ordinary observability, and a team should plan the root CA lifecycle before enabling history signing.

In the payment scenario, with history signing enabled, the payment activity, service, or policy boundary can be configured to refuse the call unless the attested context proves that the fraud-check step has been completed, the validation has passed, and the calling agent is authorized. The attested context accompanies the request, and the downstream step relies on confirmed provenance rather than an assumption.

This is the capability that separates governing agents from merely routing them, and it is worth stating plainly for a buying committee. A gateway can allow or block a connection. It cannot prove that a required prior step happened before permitting the next one.

Audit Evidence on Demand

Every control above produces evidence, and evidence only helps if a security team can get it where it needs it. Catalyst captures workflow history, distributed traces, and API logs, each of which carries the originating App ID and component context. Export depends on the deployment model. Traces can go to any OTLP backend. Catalyst Cloud exposes metrics and API logs through the console and control-plane API, and Enterprise Self-Hosted deployments can forward metrics, traces, and logs through a customer-controlled OpenTelemetry Collector.

Each API log entry includes request and response context, the originating App ID, the component, latency, and token counts, so a reviewer sees not only that a call occurred but also which workload made it and in what context. That turns an access review into reading records rather than inferring intent from raw traffic. This blog on agent observability offers insights into agent observability.

The value shows up at the worst possible moment. When an agent does something unexpected at two in the morning, the question is what the security team has to explain. Because the API logs and workflow history were captured as the events happened, post-incident reconstruction is a query rather than a forensic reassembly from partial logs. When workflow history signing is enabled, the record is tamper-evident and fails closed if altered, which is what separates an ordinary audit log from cryptographic proof. Signing and fail-closed verification ship in Dapr 1.18. Exporting that signing audit to a security team's SIEM is on the near-term roadmap, not on the current one, so it belongs in a future evaluation.

The Questions a Security Review Should Ask

A security team evaluating agent infrastructure can reduce the decision to a few axes, and naming each axis first keeps the evaluation honest.

The first axis is provenance: whether every workload binds to an App ID represented by a SPIFFE-backed identity in the data plane, or the platform checks a credential and trusts whoever holds it.

The second axis is the enforcement point: whether authorization is decided in application code that a non-deterministic agent sits next to, or below that code, in the data plane, where the agent cannot influence it.

The third axis is proof of sequence: whether the platform can prove a prior step completed when a later step depends on it, or the downstream tool simply assumes it did.

The fourth axis is evidence: whether a signed and identity-tagged record exists when an auditor asks what an agent did last Tuesday at two in the morning, or the team reconstructs one from fragments.

These questions cut in more than one direction. For an enterprise buyer, they are the criteria to demand before an agent platform touches production data. For vendors selling agent frameworks and gateways, the capabilities to build or defend are the ones that survive a security review, because a control that lives only in a slide deck does not. A platform team caught between the two gets a concrete checklist rather than a vague sense that agents need to be secured.

Gateway Routing Versus Data-Plane Security

It's helpful to clarify a common source of confusion in the market, as it influences what a procurement team needs to ask for. MCP gateways and API gateways solve discovery and routing. They typically decide where a call goes and whether the route is allowed, and many add credential management and basic access control. This is useful, but it differs from determining whether a particular agent with a certain identity, in a specific execution context, can perform a specific action. Diagrid draws the same line in explaining why MCP gateways are not enough: gateways handle discovery and routing, while identity, authorization, and proof require a separate layer.

The table below separates the two concerns. The rows specify requirements that a security team can verify independently, rather than relying on trust-based verdicts.

Real-world agent deployments often run a gateway and Catalyst together, the gateway handling ingress and Catalyst handling identity and policy for every agent-to-tool call. The key point is not that a gateway is unnecessary. Instead, gateway routing by itself leaves open critical gaps in identity, authorization, and attestation - the gaps that a security review focuses on.

Why Security Leaders Belong in the Conversation Now

Agent identity is a workload identity issue that affects security teams, whether or not they were involved in its development. Catalyst provides a solution aligned with their existing workflows, an App ID for each workload as its logical identity, backed at runtime by a short-lived SPIFFE SVID that the managed data-plane sidecar carries, authorization implemented below application code, attestation to verify that a prior step was completed before the next begins, durability and verifiability that together keep a workflow running and prove what it did, and observability that exports to the OTLP and self-hosted backends a security team already operates.

Built on Dapr, a graduated CNCF project, and on open standards, this is infrastructure a security organization can adopt without betting on a proprietary runtime. A security leader who enters the agent conversation early gets to set these controls as defaults. One who enters late inherits whatever the development teams already shipped.

The techniques discussed in this post revolved around identity-tagged records and signed history, which raises a second question. When agents run non-deterministically across many steps and tools, how does a platform team see what is actually happening? That is the focus of the next post, on observability for agent workflows.