Skip to content

Security Model ​

MAP's security model is built on one assumption: the biggest failure in assistant systems is giving too much authority, too much context, and too much data access to the assistant itself. MAP moves execution into narrow, company-controlled micro-agents and makes authority explicit, temporary, local, and auditable.

Security objectives ​

  • prevent broad authority from accumulating in the external assistant
  • keep sensitive credentials close to the systems that use them
  • require local policy evaluation before sensitive execution
  • minimize upstream context and data leakage
  • ensure every state-changing action is attributable
  • reduce the blast radius of prompt injection or assistant misbehavior

Threat model ​

MAP assumes the following threats are realistic.

1. Assistant Misalignment ​

An external assistant may misunderstand intent, over-act, or be influenced by prompt injection or context confusion.

2. Overpowered Assistant Integrations ​

An assistant may be given direct access to dangerous capabilities such as payments, database writes, administrative actions, or sensitive internal APIs.

3. Upstream Context Leakage ​

Sensitive output may be pushed into the assistant context when raw system responses, internal traces, or large data payloads are returned upstream.

4. Credential Misuse ​

Credentials exposed to the assistant or a shared integration layer may be reused outside the intended task.

5. Policy Bypass ​

High-risk actions may occur without deterministic checks if policy is treated as an application detail instead of a protocol-level control.

6. Unbounded Delegation ​

A micro-agent may gain or pass on more authority than the original request should allow.

Security principles ​

PrincipleMeaning
Company-Owned ExecutionExecution authority stays with the organization that owns the underlying system, not with the external assistant.
Capability ScopingEach micro-agent exposes only a narrow declared capability surface.
Credential LocalitySecrets, signing keys, and execution credentials remain local to the micro-agent runtime or a trusted vault adjacent to it.
Task-Scoped AuthorityAuthority is granted through short-lived delegation tokens scoped by action, resource, requester, time window, thresholds, and approval state.
Policy Before ExecutionHigh-risk actions are evaluated against local policy before state changes occur.
Output MinimizationThe default response back to the assistant is a minimal structured result plus receipt, not the full internal execution trace.
Verifiable AuditState-changing actions generate tamper-evident execution receipts.

Trust boundaries ​

MAP defines five explicit trust boundaries:

  1. user to external assistant
  2. external assistant to MAP control plane
  3. control plane to company micro-agent
  4. company micro-agent to local adapter
  5. local adapter to underlying system

Signature scopes ​

Every protocol artifact is signed, not just receipts. MAP defines eight signature scopes:

ScopeSigned artifact
descriptorAgent descriptor documents
delegation_tokenShort-lived task authority tokens
receiptExecution receipts
http_requestTransport-level signed requests
audit_checkpointHash-chained audit checkpoints
audit_exportExported audit bundles
conformance_exportConformance evidence bundles
trust_bundleVerification keys and trust metadata

Replay protection ​

HTTP signing headers include a unique nonce and a timestamp that must be within a plus-or-minus five minute window:

  • x-map-nonce - unique per request, rejects replayed traffic
  • x-map-timestamp - must fall inside the accepted clock window

Visibility modes ​

MAP controls not just what agents do but what they see back. The requested_output_mode envelope field selects:

ModeBehavior
fullComplete structured output
summaryMinimized summary of the result
structured_onlyStructured fields without free-form traces
redactedSensitive fields stripped
receipt_onlyOnly the signed receipt is returned upstream
debugFull internals for troubleshooting (never in production policy)

This is the data-exfiltration story: even a compromised assistant cannot pull internal execution traces upstream when the policy pins the mode to summary or receipt_only.

Hardening details ​

Built into the reference server:

  • SSRF protection that blocks 0.0.0.0, IPv6, and AWS metadata addresses
  • prototype-pollution protection in the body parser
  • admin token hashing (SHA-256) with timing-safe comparison
  • file permissions: 0700 for directories, 0600 for the dead-letter store
  • HMAC secret rotation support

Deployment profiles ​

ProfileUse caseSigned requestsTenant requiredKey algorithm
openDevelopmentOptionalOptionalHS256 or RS256
verifiedStaging / ProductionRequiredOptionalRS256 only
regulatedFinance / HealthcareRequiredRequiredRS256 only
bash
MAP_DEPLOYMENT_PROFILE=regulated

EU AI Act compliance ​

The EU AI Act requires audit trails for high-risk AI systems. MAP provides:

  • tamper-evident audit event log (GET /audit-events)
  • cryptographically signed execution receipts
  • hash-chained audit checkpoints with verifiable integrity
  • policy decision records showing which rule triggered and why
  • human oversight via the approval workflow
  • export-ready audit data

Released under the Apache 2.0 License.