Zero-Trust Security for Agent Networks

Enterprise agent networks introduce a security challenge that traditional perimeter-based models were never designed to handle: agents operate as autonomous callers inside your network, making hundreds of internal API calls per task, and any one of them can be compromised through prompt injection, dependency vulnerabilities, or stolen credentials. Applying zero-trust architecture, never trust, always verify, to agent networks eliminates implicit internal trust and contains the blast radius of any single agent compromise.

Why Perimeter Security Fails for Agent Networks

The perimeter model draws a hard line between “outside” (untrusted) and “inside” (trusted). Everything inside the VPN or private subnet is granted broad internal access. This model was designed for human users sitting at workstations, it was not designed for autonomous agents that generate thousands of internal API calls per hour.

Three properties of agent networks make the perimeter model dangerous:

Agents are callable attack surfaces. An agent that accepts natural-language instructions can be manipulated through prompt injection, an attacker who controls a document the agent reads can embed instructions that redirect the agent’s tool calls. A compromised agent inside your perimeter has the same network access as a legitimate one.

Lateral movement is trivially easy. If Agent A calls Agent B over plain HTTP inside a VPN, and Agent A is compromised, the attacker can replay those calls or forge new ones. Without per-call authentication, Agent B has no way to distinguish a legitimate call from Agent A versus a forged one.

Blast radius is unbounded. Without authorization checks on internal calls, a single compromised agent can read every internal service it can route to. In a network of 50 agents, that is a catastrophic exposure surface.

flowchart TD
    EXT["External Input\n(document, API, webhook)"] --> PA["Planner Agent"]
    PA --> DA["Data Agent"]
    PA --> RA["Report Agent"]
    DA --> DB[("Internal\nDatabase")]
    RA --> HR[("HR System")]

    COMP["Compromised DA\n(via prompt injection)"] -.->|"lateral move\n(no auth check)"| HR
    COMP -.->|"exfiltrate data"| ATK["Attacker"]

    style PA fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style DA fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style RA fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style COMP fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style DB fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style HR fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style EXT fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style ATK fill:#fff7ed,stroke:#f59e0b,color:#0F172A

SPIFFE/SPIRE for Cryptographic Agent Identity

Zero-trust requires every agent to carry a cryptographic identity that can be verified on each call. SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE provide exactly this: workload identity certificates issued to Kubernetes pods based on attestable properties.

Each agent pod receives an X.509 SVID, a short-lived certificate (default TTL: 1 hour, rotated automatically) that encodes the agent’s SPIFFE ID in the form spiffe://trust-domain/ns/agent-namespace/sa/data-agent. When Agent A calls Agent B, they perform mutual TLS using their SVIDs. Agent B can cryptographically verify that the caller is the data-agent service account in the agent-namespace, not just “something inside the cluster.”

sequenceDiagram
    participant SA as SPIRE Agent (node sidecar)
    participant SS as SPIRE Server
    participant DA as Data Agent Pod
    participant RA as Report Agent Pod

    DA->>SA: Request SVID (workload attestation)
    SA->>SS: Attest node identity (k8s node attestor)
    SS-->>SA: Node identity confirmed
    SA-->>DA: Issue X.509 SVID (TTL: 1h, auto-rotated)

    DA->>RA: mTLS call presenting SVID
    RA->>RA: Verify DA SVID against trust bundle
    RA-->>DA: Response (only if SVID valid + authorized)

The critical operational detail: SPIRE automatically rotates SVIDs before they expire. Your agents never manage certificate lifecycle, the SPIRE agent sidecar handles it. This means a compromised agent’s credentials expire within the hour even if the compromise has not yet been detected.

Short-Lived JWT Tokens with Narrow Scopes

For calls to REST APIs and tool endpoints, mTLS establishes transport identity. You also need application-layer authorization tokens that encode what the agent is permitted to do, not just who it is.

Issue JWT tokens with three constraints: a short expiry (5-15 minutes maximum, refreshed via a token endpoint authenticated with the agent’s SVID), a narrow scope tied to the exact tool being called (scope: "read:financial-records" not scope: "read:*"), and audience binding so the token is only valid for the specific service it targets.

import jwt
import time
from dataclasses import dataclass

@dataclass
class AgentTokenRequest:
    agent_id: str
    tool_name: str       # e.g. "read_financial_records"
    target_service: str  # e.g. "financial-db-service"
    spiffe_svid: str     # presented to authenticate the token request itself

def issue_agent_token(req: AgentTokenRequest, signing_key: str) -> str:
    now = int(time.time())
    payload = {
        "sub": req.agent_id,
        # Narrow scope tied to a single tool: not a wildcard.
        # Stealing this token only compromises one operation, not the whole agent.
        "scope": f"tool:{req.tool_name}",
        # Audience binding prevents replay against other services even if token is stolen.
        "aud": req.target_service,
        "iat": now,
        # 10-minute expiry: short enough to limit the compromise window,
        # long enough to complete a typical tool invocation sequence.
        "exp": now + 600,
    }
    return jwt.encode(payload, signing_key, algorithm="RS256")

def verify_agent_token(token: str, expected_scope: str, public_key: str) -> dict:
    # Verify signature, expiry, and audience binding in one call.
    # Never silently accept tokens with invalid claims: raise on any failure.
    claims = jwt.decode(
        token,
        public_key,
        algorithms=["RS256"],
        audience="financial-db-service",
    )
    if claims["scope"] != expected_scope:
        raise PermissionError(
            f"Token scope '{claims['scope']}' does not match required '{expected_scope}'"
        )
    return claims

Network Segmentation and Prompt Injection Defense

Kubernetes NetworkPolicy provides a declarative layer of network segmentation independent of your application code. Even if an agent’s mTLS certificate is stolen, NetworkPolicy can restrict which pods it can reach at the kernel level. Define policies that allow only necessary communication paths: the planner agent can reach worker agents, worker agents can reach their designated data services, and no agent can reach the SPIRE server directly, only the SPIRE agent sidecar on the node can.

At the API gateway layer, the entry point for external data reaching your agent network, add a prompt injection filter. This catches the vast majority of known injection patterns: role-reassignment phrases, system-prompt override attempts, and encoded payloads.

import re
from typing import Optional

# Patterns ordered by severity: stop at first match to minimize added latency.
INJECTION_PATTERNS = [
    r"ignore (all |previous |prior )?instructions",
    r"system prompt\s*[:=]",
    r"you are now (a |an )?(?!assistant)",   # role reassignment attempt
    r"disregard (your |the )?(previous |prior )?",
    r"act as (a |an )?\w+(?! assistant)",
]
_COMPILED = [re.compile(p, re.IGNORECASE) for p in INJECTION_PATTERNS]

def screen_for_injection(text: str) -> Optional[str]:
    """
    Returns the matched pattern if injection is detected, else None.
    Called at the gateway BEFORE any content is forwarded to an agent.
    We log the pattern name, not the matched text, to avoid storing
    attacker payloads verbatim in audit logs.
    """
    for pattern in _COMPILED:
        if pattern.search(text):
            return pattern.pattern
    return None

The gateway should log every detection, block the request with a 400 response, and emit a security alert. A sustained spike in injection attempts targeting a specific agent endpoint is a signal that warrants immediate investigation, it may indicate targeted reconnaissance of that agent’s capabilities.

flowchart TD
    IN["Inbound External Data"] --> GW["API Gateway\n(injection filter)"]
    GW -->|"clean"| AGT["Agent Network\n(mTLS + SVID)"]
    GW -->|"injection detected"| BLK["Block + Alert"]
    AGT --> TOK["Token Service\n(short-lived JWT)"]
    AGT --> NP["NetworkPolicy\n(k8s layer)"]
    TOK --> SVC["Internal Services"]
    NP --> SVC

    style IN fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style GW fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style AGT fill:#EEF0F7,stroke:#6366F1,color:#0F172A
    style BLK fill:#fff7ed,stroke:#f59e0b,color:#0F172A
    style TOK fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style NP fill:#f0fdf9,stroke:#0D9488,color:#0F172A
    style SVC fill:#f0fdf9,stroke:#0D9488,color:#0F172A

Zero-trust is not a product you install, it is an architecture you build layer by layer. SPIFFE/SPIRE gives you cryptographic workload identity, mTLS gives you authenticated transport, short-lived scoped JWTs give you application-layer authorization, NetworkPolicy gives you network segmentation, and gateway injection filtering gives you boundary defense. Each layer assumes the others can fail. The next lesson extends this foundation with role-based access control policies that govern exactly what each authenticated agent is permitted to do.