Security

MAP's security model is defense in depth. No single layer protects you; every layer must hold. This page describes each layer and how they compose.

The threat model

MAP is designed to operate in environments where:

• Autonomous agents act on behalf of human principals
• Calls cross organizational boundaries under treaty
• Credentials must not leak to agents that use them
• Every action must be attributable and auditable
• The substrate itself may be one of many adversarial principals' targets

The model assumes the gateway, the engine, and the audit chain are all in scope for adversaries. The protections are layered such that compromise of any one does not compromise the institution.

Layers

1. Transport — TLS

Every connection terminates TLS 1.3 at the gateway. Rustls (no OpenSSL). Default cert via the platform (Let's Encrypt on Vercel, Fly.io certs on Fly). Sovereign deployments bring their own CA and chain.

[gateway.tls]
min_version = "1.3"
ciphersuites = [
    "TLS_AES_256_GCM_SHA384",
    "TLS_CHACHA20_POLY1305_SHA256",
    "TLS_AES_128_GCM_SHA256"
]

2. Identity — MACS verification

Before any request enters the engine, MACS::verify_response runs:

1. Verify the Ed25519 signature on the presented envelope
2. Resolve the OAS DID document
3. Walk the lineage chain to a human root
4. Compute the effective capability set (declared + delegated + treaty)

The verification is offline-possible — the lineage chain plus the leaf signature suffice. See Identity & lineage.

3. Capability — SecurityGateway

Every operation requires a matching capability. Hierarchical matching at Stage 4:

map.{protocol}.{operation}   →  exact match required first
map.{protocol}.*             →  protocol wildcard
map.*.*                      →  admin wildcard (rare)

Capabilities cannot be amplified through delegation — Aegis::delegate enforces this at delegation time and MACS::derive re-verifies at every request.

See Capabilities.

4. Policy — MAXIM

MAXIM evaluates the active policy bound to the tenant for every request. Policies are written in Cedar (or Logos for institutions that prefer it). Refusal returns the policy rule that fired and the facts that triggered it.

permit (
    principal in TrustedAgents,
    action == Action::"map.market.execute_trade",
    resource is Trade
)
when {
    resource.size_usd < 100000
    && principal.merit.score >= 80
    && context.time_of_day in ["09:00".."17:00"]
};

5. Credential proxy — Arsenal

The hardest layer: agents need to call third-party APIs that require credentials. Arsenal solves this by issuing Agent Capability Tokens (ACTs) bound to the caller, capability, and credential reference — the agent never sees the credential.

The 11-step proxy:

1. Agent calls Arsenal proxy with intent + ACT
2. Arsenal verifies ACT and caller identity
3. Arsenal looks up the credential by reference
4. Arsenal validates the outbound URL (SSRF guard + DNS-rebinding defense)
5. Arsenal substitutes the credential at the wire (e.g., adds Authorization: Bearer ...)
6. Arsenal sends the request
7. Arsenal receives the response
8. Arsenal records to the hash-chained audit
9. Arsenal redacts the response if necessary
10. Arsenal returns the redacted response to the agent
11. Arsenal optionally triggers HITL consent for new credential surfaces

See Arsenal adapter.

6. Sandbox — Wasmtime 37

Tier-2 plugins run in Wasmtime's memory sandbox with the WASIP2 component model. Plugins:

• Cannot read host memory outside their imports
• Cannot make raw syscalls
• Cannot allocate memory beyond their declared limit
• Cannot run beyond their declared CPU budget (fuel + epoch)
• Can only call host functions explicitly imported in their wit interface

Compromised plugins cannot affect other plugins or the host.

7. Audit — MAX

Every layer's decision flows to MAX::audit_log_entry. The chain is hash-linked and signed; compromise of an in-flight operation cannot rewrite history. See Concepts → Audit.

Plugin signing

Tier-2 WASI plugins must be signed by a publisher whose DID is in trusted_publishers. Tier-3 external HTTP plugins authenticate to the engine via DID-Auth.

[plugins]
require_signatures = true
trusted_publishers = [
    "did:oas:l1fe:agent:0x...",        # L1fe official
    "did:oas:acme:agent:0x...",        # Acme — our institution
    # ...
]

Unsigned or invalidly-signed plugins enter Pending state and emit a PluginRejected audit event. They cannot be promoted to Registered without a valid signature.

Secret management

MAP itself stores secrets in:

MAP never stores customer DID private keys. Customers retain custody; MAP verifies signatures against the OAS document. This is what makes sovereign deployment trustworthy — your keys never touch our infrastructure.

Auth profiles

MACS supports multiple auth profiles, configured per tenant:

Most production traffic uses DidAuth. Human ingress through the admin console uses OAuth2.

Sovereign deployment posture

For air-gapped or on-prem deployments:

• No outbound telemetry — MAP_OTEL_ENDPOINT unset, no metrics push
• Local OAS mirror — DID resolution against an internal registry
• Bring-your-own CA — TLS chain bound to your CA
• Local plugin signing — trusted_publishers configured to your own keys only
• Customer-owned audit signing — engine signs audit records with a key in your custody

The same engine binary runs sovereign-mode and SaaS-mode. Configuration is the only difference.

Reporting vulnerabilities

If you discover a security issue, report to security@l1fe.ai with full reproduction steps. We follow a 90-day coordinated disclosure window. Critical findings (CVSS ≥ 9.0) receive same-day patches.

See also

• Engine pipeline — where security gating runs
• MACS — identity verification
• Arsenal — credential proxy
• Aegis — keys & delegation
• Plugins — signing
• Concepts → Audit