Webinar Recap: Who Let the Agents Out? Your client_id Is Not An Identity

Recap of the May 20, 2026 Diagrid webinar

The second installment of Diagrid's "Can your AI platform do this?" series tackled security in agentic systems. Where the first webinar focused on bringing durability to LangGraph, this webinar focused on what happens when agents connect to MCP servers, databases, and CRMs in production, and why identity is required by teams for zero trust security.

The core problem

Start with a question of expectations. Organizations would never onboard a human employee without a way to track what they accessed, when, and from where. Audit logs, identity records, and revocation procedures are standard for people. Agents and MCP servers, by contrast, get deployed into production with security treated as a follow-up item. When something goes wrong, revocation is slow, and downstream workflows keep running on stale or compromised access.

Prompt injection makes the problem worse. Agents generate SQL queries and tool calls non-deterministically based on whatever ends up in the prompt. That gives attackers a path to widen the blast radius far beyond what the system was originally scoped to do. Without strong identity, MCP servers become force multipliers for destructive agent behavior.

Identity is the foundation

The framing question for the rest of the session: every piece of data an agent touches, is it entitled to touch? Existing identity systems answer that well for two cases. Humans get directory accounts with file and directory permissions. Deterministic business processes get static API keys and service accounts with scopes known in advance. Agents fit neither pattern. They behave more like humans, exploring tools and systems based on goals rather than scripts, but they need something more than a client_id and a bearer token to be trusted.

What is actually needed goes further. Identities for agents have to be cryptographically attestable. They have to carry across workflows so downstream services can verify provenance and intent. They have to be tied to policy that can be enforced and audited at runtime. Just-in-time access matters here because the scope of what an agent does depends on what the LLM produces in the moment, not what was planned at deployment.

A-Auth, the agentic extension of OAuth, improves on static identity for agents but does not address the broader problem. Identity without enforceable policy at every step of the workflow leaves gaps. For more on why agent identity is the missing layer in enterprise AI, see AI agent identity: the missing layer.

Why MCP gateways are not enough

Many vendors at MCP DevCon in March positioned MCP gateways as the security answer for agentic systems. The honest read is that gateways function as castle walls. They sit at the north-south entrance to the system and apply OAuth flows there. Once a request gets past the wall, the gateway has no further role. It operates at the network level and does not provide cryptographic attestation that can travel through the workflow. Useful as a perimeter, insufficient as an identity system. For the full argument, see Why MCP gateways are not enough.

SPIFFE, Dapr, and Diagrid Catalyst

The technical foundation is SPIFFE, a CNCF project that issues identities in a standardized format embedded in JWT tokens or x.509 certificates. Dapr, which graduated from the CNCF and provides durable workflows, service invocation, and pub/sub, has shipped with a SPIFFE-based certificate authority from day one. Every workload connected to Dapr gets a cryptographically attestable certificate with an embedded SPIFFE ID, no secrets to manage, lifecycle handled automatically.

Diagrid extends SPIFFE with an app ID concept. Any application that is connected gets an identity, and platform teams can attach declarative policies to it. Catalyst, Diagrid's commercial platform, builds on Dapr, and SPIFFE, to bring this model to MCP and agentic workloads. In fact any piece of code, whether this is an agent, MCP server or application can be assigned a cryptographic identity used for authentication and hence authorization of exactly what that code is allowed to do. Catalyst provides zero trust security through the use of these identities, with full control over what workload can access what resources given to the platform team.

The demo

The live demo is worth watching in full. The setup ran three agents and a single MCP server exposing four tools against a local Postgres database, with no Catalyst-specific code in the MCP server itself. All the agents and the MCP server were assigned identities.

From there, the demo used those identities from a blanket deny-all policy applied with a single CLI command, to granular per-agent, per-tool access controls, all performed through declarative YAML and visible in real time through the Catalyst UI. The audit log, topology graph (relationship between the workloads with identities), and live traffic views show how cryptographically attested identities flow through the system. The repo is available at github.com/diagridio/catalyst-mcp-access if you want to run it yourself.

Beyond agents and MCP servers, databases, message brokers, and LLM providers can be onboarded as first-class identities too. Catalyst can scope a Postgres or DynamoDB instance so only specific MCP servers can reach it, and the LLM conversation API supports PII redaction for traffic to OpenAI, Anthropic, or Mistral.

Trust domains

A trust domain is a logical boundary that defines the scope of identity and trust relationships. It acts as a foundational element for zero-trust security, governing how applications, MCP servers and agents authenticate, communicate, and authorize actions across different environments.

What's next

Diagrid Catalyst brings security, governance, durable workflows, and reliability together in one platform. The preview at the end pointed to attestation chain of custody, a feature landing in Dapr 1.18 that ties identity attestation to workflow execution history. A dedicated webinar on that is planned for a future episode.

The takeaway: identity is the foundation of zero trust for agents, and a public client_id using OAuth alone does not get you there.