Security Model

This page documents the security posture of AI Agent Assembly for enterprise security and compliance teams.


IronClaw Five-Layer Defense

AI Agent Assembly organizes its security controls into five named layers. Each layer is independently deployable and adds defense-in-depth:

LayerNameWhat it does
1BoundaryNetwork perimeter: sidecar proxy (aa-proxy) enforces egress policy; eBPF sensor (aa-ebpf) catches kernel-level bypass attempts
2IdentityAgent and user authentication: JWT-based agent identity issued by the gateway; operator authentication via SAML 2.0 / OIDC SSO
3PolicyRuntime governance: YAML/JSON policy rules evaluated by the gateway policy engine before every agent action
4VaultSecret and credential management: AES-256-GCM encryption at rest for stored secrets; Ed25519-signed tokens for inter-component trust
5TelemetryAudit and observability: append-only event log for every agent action; Slack/webhook connectors for real-time alerting on policy violations

STRIDE Threat Model

The table below maps each STRIDE category to the five primary components of AI Agent Assembly and the mitigating controls in place.

ComponentSpoofingTamperingRepudiationInfo DisclosureDenial of ServiceElevation of Privilege
Language SDKEd25519-signed agent tokens prevent impersonationSDK integrity verified by Cargo/npm/PyPI package hashEvery call logged with agent ID and timestampSDK communicates over mTLS; secrets never loggedRate limiting enforced by gateway budget trackerPolicy engine enforces agent scope; no ambient privilege
Gateway (aa-gateway)JWT validation on all gRPC connectionsInput validation on all RPCs; schema-enforced policy rulesAppend-only audit log with tamper-evident signaturesInternal-only gRPC endpoint; never exposed directlyPer-team budget caps block runaway agent spendingRBAC on all administrative API endpoints
Sidecar Proxy (aa-proxy)Per-host CA pinning prevents MitM spoofing by agentsTLS termination with certificate validation on every upstreamAll intercepted requests logged by proxy before forwardingProxy does not log request/response bodies by defaultConnection pool limits per agent; circuit breaker on upstream failureProxy runs as unprivileged user; no write access to host filesystem
eBPF Sensor (aa-ebpf)eBPF program loaded only by privileged system serviceBPF verifier rejects unsafe programs at load timeKernel event timestamps are monotonic; cannot be retroactively alteredeBPF only reads SSL buffers; no access to unrelated memory regionseBPF programs have bounded execution; verifier enforces loop limitsLoaded via CAP_BPF only; capability is dropped after program load
REST API (aa-api)SAML/OIDC token validation on every requestOpenAPI schema validation rejects malformed inputsAll mutating API calls logged with actor identityHTTPS-only; HSTS enforced; no sensitive data in query stringsRate limiting per IP and per tenant; DDoS mitigation via upstream load balancerTenant isolation enforced at API layer; cross-tenant access rejected

Traceability: Each STRIDE row maps to a specific IronClaw layer control. For configuration paths and runbook references, consult the security runbook in the agent-assembly repository.


Cryptographic Primitives

PrimitiveAlgorithmKey lengthUsageRotation cadence (NIST SP 800-57)
Agent signing keyEd25519256-bitSigns agent identity tokens issued by the gatewayEvery 90 days or on compromise
Vault encryptionAES-256-GCM256-bitEncrypts secrets and credentials at restEvery 1 year or on compromise
Callback / webhook signatureHMAC-SHA256256-bitSigns outbound webhook payloads so receivers can verify authenticityEvery 90 days or on rotation of webhook secret
TLS (transport)TLS 1.3ECDHE-256All inter-component and external communicationCertificate: every 90 days (auto-renewed)

All keys are generated using a CSPRNG. No MD5, SHA-1, or DES primitives are used anywhere in the stack.


Authentication Flow

SDK → Gateway (gRPC)

sequenceDiagram
  autonumber
  participant SDK as Language SDK
  participant GW as aa-gateway

  SDK->>GW: RegisterAgent(agent_id, public_key, metadata)
  GW-->>SDK: AgentToken (Ed25519-signed JWT, TTL=1h)
  Note over SDK,GW: All subsequent calls carry the AgentToken in gRPC metadata

  SDK->>GW: CheckPolicy(event) [+ AgentToken]
  GW->>GW: Verify Ed25519 signature, check TTL
  GW-->>SDK: PolicyDecision

Operator → Dashboard / CLI (SAML/OIDC)

sequenceDiagram
  autonumber
  participant Ops as Operator
  participant CLI as aasm CLI / Dashboard
  participant API as aa-api
  participant IdP as Enterprise IdP (SAML/OIDC)

  Ops->>CLI: aasm login --sso
  CLI->>IdP: Redirect to IdP with SAML AuthnRequest
  IdP-->>Ops: Login prompt (MFA enforced by IdP)
  Ops->>IdP: Credentials + MFA
  IdP-->>CLI: SAML Assertion / OIDC id_token
  CLI->>API: Exchange assertion for session token
  API-->>CLI: Signed session token (TTL=8h)
  CLI-->>Ops: Login successful

Secrets Management

  • Secrets (LLM API keys, webhook tokens) are stored encrypted with AES-256-GCM.
  • The encryption key is derived from a master secret held in the SaaS control plane's hardware security module (HSM).
  • Secrets are never written to disk in plaintext.
  • Secrets are never logged, even at DEBUG level.
  • Secret rotation is supported via the aasm secret rotate command, which re-encrypts in place without service restart.

Audit Log

  • Every agent action (policy check, event record, budget debit) produces an immutable log entry.
  • Log entries are signed with HMAC-SHA256 using a log-signing key.
  • Logs are append-only; no delete or update API exists.
  • Log retention: configurable per tenant (default: 90 days).
  • Logs are exportable in JSON or CEF format for SIEM integration.

Compliance Posture

StandardStatus
SOC 2 Type IIIn preparation (target: Q3 2026)
ISO 27001Roadmap (post-SOC 2)
GDPRArchitecture is GDPR-compatible; DPA available on request
CCPACovered under SaaS Data Processing Agreement


Last reviewed: 2026-05-10 — AI Agent Assembly Team