SAGA: A Security Architecture for Governing AI Agentic Systems

SAGA: A Security Architecture for Governing AI Agentic Systems

Speakers: Georgios Syros

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=NZvfPHAciyE

Overview

As AI agents proliferate across enterprise and consumer applications, their interactions remain completely ungoverned and insecure. Emerging protocols like Google's Agent-to-Agent (A2A) and Microsoft's AG2 focus on interoperability, not security. This talk introduces SAGA (Security Architecture for Governing AI Agentic Systems), the first comprehensive security architecture for multi-agent systems that provides verifiable agent identities, policy-enforced access control, and secure agent-to-agent communication. Formally verified in both Verifpal and ProVerif, SAGA scales to 200 million coexisting agents on AWS, adds less than 0.6% overhead to LLM task inference time, and successfully mitigates eight concrete attack models including unauthorized agents, impersonation, token misuse, and Sybil attacks.

Background

▶ Watch: The ungoverned state of AI agent interactions today (0:00)

AI agents -- autonomous software that reasons, plans, collaborates, and delegates tasks -- are being deployed rapidly through frameworks like Anthropic's Agent SDK and OpenAI's Frontier. But the security infrastructure has not kept pace. A new class of inter-agent attacks has emerged where malicious agents target benign agents through communication, subverting them via direct prompt injection to exfiltrate data, corrupt databases, or perform other adversarial actions. Rogue agents can compromise legitimate ones, force agent self-replication, and perform Sybil attacks.

OpenAI's AI governance white paper identified four key requirements for agentic AI systems: unique and verifiable agent identities, secure agent discovery and communication, fine-grained resource access control, and user oversight throughout the agent lifecycle. Three core challenges underpin these requirements: discovery (how agents find each other), secure communication (how agents talk to each other), and access control (which agents can interact, for what tasks, and for how long).

No existing infrastructure solves all three. Google's A2A provides no security guarantees or access control. Model Context Protocol (MCP) is about tools, not agent-to-agent communication. SAGA addresses this complete gap.

Key Findings

▶ Watch: SAGA architecture: provider, users, and agents (4:00)

Formal Verification: SAGA's protocols were formally verified in both Verifpal and ProVerif for authentication of registration, authentication of communication, and secrecy of communication.

Eight Attack Models Mitigated: SAGA successfully defends against unauthorized agents, compromised agents, impersonation attacks, token misuse, Sybil attacks, and several additional threat scenarios.

Minimal Overhead: Cryptographic costs are at most 7 milliseconds per token-regulated communication. Registration (both user and agent) is a one-time cost under 200 milliseconds. Protocol overhead stays below 0.6% of total LLM task inference time and amortizes quickly as the number of requests per token grows.

Massive Scale: On AWS with seven shards and 24-hour token lifetimes, SAGA supports approximately 200 million coexisting agents. On a conventional workstation, the provider sustains 100,000 requests per minute. Capacity scales linearly with shard count -- going from 1 to 7 shards increases capacity from roughly 50 million to almost 300 million agents.

Interoperability: SAGA integrates with Google's A2A protocol. Agent cards (A2A's capability advertisements) are protected with SAGA's cryptographic signatures, and A2A messages are encapsulated within SAGA's secure communication layer, enabling existing A2A-compatible agents to benefit from SAGA's security with minimal changes.

Technical Deep Dive

▶ Watch: Fault tolerance with Raft consensus and sharding (8:00)

SAGA has three components: a provider (managing registries and enforcing access control), users (registering agents and defining contact policies), and agents (requesting access and communicating).

User Registration: A user generates a signed identity (e.g., email-based identifier) and a certificate authority-certified key pair, submitting them to the provider. An external human identity verification service must approve the user before they are added to the registry. This prevents agents from registering themselves as users, ensuring traceable human-bound identities.

Agent Registration: When registering an agent, the user signs its metadata: an agent identifier (extending the user identifier), device information, IP/port, cryptographic keys, and critically an Access Contact Policy (ACP). The ACP maps agent identifiers to communication budgets with pattern-based matching. For example: "allow all calendar agents from company X with budget 10 requests" or "allow specific trusted agent Y with budget 15." The provider verifies signatures, checks metadata uniqueness, and returns a signed proof. Every agent is cryptographically bound to its user.

Inter-Agent Communication: When agent B wants to contact agent A:

1. B requests access from the provider
2. If A's ACP permits it, B receives A's metadata and a one-time key
3. A and B perform a Diffie-Hellman key exchange to derive a shared secret
4. A encrypts an Access Control Token (ACT) with the shared secret
5. The ACT encodes expiration timestamps, request quotas, and is scoped to specific tasks
6. B attaches the ACT to all subsequent messages to A
7. Direct communication -- no provider involvement after token issuance
8. When the token expires, B must request a new one-time key

Fault Tolerance: The provider uses Raft consensus -- a distributed agreement protocol that keeps registries running even with faulty replicas. Scalability is achieved through sharding, with each shard itself fault-tolerant via Raft. Three-node Raft per shard is the optimal configuration, performing nearly identically to five-node while tolerating one failure.

Agent Revocation: When a malicious agent is identified, the provider removes its metadata from the registry. Any subsequent access attempts return a revocation message. Even agents with cached metadata cannot communicate because they need a one-time key from the provider to derive new access control tokens.

Demo / Proof of Concept

▶ Watch: Formal verification and eight attack models mitigated (10:00)

SAGA was evaluated across four dimensions:

• Security: Formally verified in Verifpal and ProVerif; eight attack models successfully mitigated
• Performance: 7ms cryptographic cost per communication, <200ms registration, <0.6% overhead on LLM inference tasks
• Scalability: Linear capacity growth with shards; 200 million agents on AWS with seven shards
• Fault tolerance: Provider continues operating with up to two simultaneous replica failures per shard (five-node Raft)

The system was tested with real agentic tasks including meeting scheduling, email composition, and scientific writing, confirming that protocol overhead is negligible relative to LLM inference time.

Defensive Implications

▶ Watch: Q&A: Agent discovery, federation, and task-level granularity (14:00)

SAGA addresses what may be the most critical infrastructure gap in the AI agent ecosystem:

Accountability: The most important contribution is establishing traceable, human-bound identities for agents. Currently, agents communicate freely across the internet with no identity verification, no access control, and no accountability. When a malicious agent causes damage, it ceases to exist with no trail. SAGA ensures every agent is cryptographically bound to a verified human user.

Policy-Based Access Control: The Access Contact Policy gives users explicit control over who can contact their agents and with what budget. This is analogous to firewall rules for agent communication -- a fundamental capability that currently does not exist.

Enterprise Readiness: For organizations deploying multi-agent systems, SAGA provides the governance framework needed for compliance and risk management. The formal verification, revocation capability, and audit trail address regulatory requirements around AI system governance.

A2A Integration: The ability to layer SAGA's security on top of Google's A2A protocol means organizations can adopt A2A for interoperability while adding security guarantees, rather than having to choose between the two.

Limitations: SAGA governs access, not behavior. It does not defend against prompt injection or control what tasks an authorized agent performs. The team has separate work addressing prompt injection that complements SAGA. The architecture also currently requires agents to know each other's identifiers beforehand, though public registries could be added.

Key Takeaways

• SAGA is the first security architecture for AI agentic systems, providing verifiable identities, policy-enforced access control, and secure inter-agent communication
• Formally verified in Verifpal and ProVerif, with eight concrete attack models successfully mitigated including Sybil attacks and impersonation
• Protocol overhead is less than 0.6% of LLM inference time, with 7ms per token-regulated communication and sub-200ms registration
• Scales to 200 million coexisting agents on AWS through sharding and Raft consensus
• Integrates with Google's A2A protocol, adding security to existing interoperability infrastructure
• Establishes traceable human-bound agent identities -- solving the accountability gap in current agentic AI systems

About the Speaker(s)

Georgios Syros (presenting as Yorgos) is a researcher at Northeastern University, working with Anu Monsuri, Jacob Vinesen, and advisors Professor Christina Narosaru and Professor Alina Prea. The research focuses on security architecture for AI systems, with SAGA representing the group's work on agent governance while complementary work addresses prompt injection defense. The full paper and code are publicly available.