Sealed Agent Identity MapReference architecture for agentic IAM · medical device edition

Sealed agent, brokered trust

A containerized AI agent gets an identity it cannot touch, a network path it cannot leave, and tools it cannot over-reach. Two perimeters do the work: the immutable container bounds the agent's identity, and the firewall and MCP pair bounds everything the organization runs. Every IAM function (identity issuance, policy, secrets) sits beyond the second one.

Hover, focus or click any part carrying a n pin for its note. The same notes are listed under each figure, and hovering a note lights up its part.

Fig. 1

Two perimeters, one way through

Perimeter 1, the immutable container, is the agentic identity perimeter: one container, one SPIFFE ID, one agent, and nothing inside it can be altered or carried out. Perimeter 2, the AI firewalls and MCP server together, is the boundary to the rest of the organization: no agent reaches a tool, a secret, policy or identity issuance except through it, and even the SPIFFE calls that give the agent its identity are inspected and brokered there. Egress and ingress are separate flows, each inspected for its own risks.

Scroll the diagram sideways on narrower windows.

Notes for Fig. 1
    Fig. 2

    SPIFFE flow, brokered through the perimeter

    The wrapper never talks to SPIRE. It proves what it is with a platform attestation, sends a CSR through the firewall chain, and the MCP identity broker obtains the SVID on its behalf. The private key never leaves perimeter 1, SPIRE stays beyond perimeter 2, and the agent process does not exist until the identity is in hand.

    Scroll the diagram sideways on narrower windows.

    Steps in Fig. 2
      Fig. 3

      Secrets never cross to the agent side

      Credentials between tools and endpoints are minted, used and expired entirely to the right of the secret boundary. The agent asks for an outcome; the MCP server supplies the credential on the way out.

      Scroll the diagram sideways on narrower windows.

      Steps in Fig. 3
        Fig. 4

        One tool registry, many agents

        Tools are registered once and shared. Policy keyed on SPIFFE ID decides which tools each agent can even see. Pick an agent to view the tools/list response the MCP server would return to it.

        • allowed
        • allowed with conditions
        • not listed · invisible to the agent

        tools/list →

        
        
        policy behind one cell
        
        
        # versioned in git · shipped as a signed bundle
allow {
  input.spiffe_id == "spiffe://agents.example.org/vigilance-review"
  input.tool == "docs.read"
  startswith(input.args.path, "risk-files/")
}
        
        
        Filtering the list is as important as authorizing the call: an agent that never learns a tool exists cannot be talked into trying it.
        
      
        
    
        
  
        

  
        
    
        Fig. 5
        AAA falls out of the choke point
        
    
        Every request is authenticated, authorized and executed at the MCP server, so one record can carry all three A's, keyed by SPIFFE ID. Hover a line of the sample record to see which component wrote it.
        
    
        
      
        Authentication
        access management · SVID check
        Which workload called: SPIFFE ID, SVID serial and expiry, verification result, failures and expired or wrong-audience tokens.
        
      
        Authorization
        access management · policy decision
        What it was allowed to see and do: decision, matched rule, policy version, the tool list returned, every denial with its reason.
        
      
        Accounting
        tool adapters · secrets broker · firewalls
        What actually happened: tool, argument hash, endpoint, latency, bytes, secret lease used, firewall verdicts, trace ID.