Sidian Labs

MAP · Micro Agent Protocol · open protocol

Every action authorized. Every decision signed.

An open protocol for governing registered agent actions through policies, approvals, and signed receipts.

The firewall for AI actions. MAP is an open protocol that enforces security policies, triggers human approvals, and generates cryptographically signed receipts for every single decision your agent makes.

Released
Source on GitHub Docs

Published on npm as @sidianlabs/map. See the install guide.

Fig. 1Illustrative

One decision, one receipt: the wire-format example from §5, signed as a JWS with typ MAPSIG.

Package
@sidianlabs/map
Reference implementation
TypeScript
Preview SDKs
Python, Go (not yet contract-aligned)
Signatures
HS256/RS256 JWS, typ MAPSIG
Conformance
Program defined; no implementations certified yet

§1 · Overview

The firewall for AI actions.

MAP is an open protocol and reference implementation for controlling what AI agents are allowed to do. You declare policy as a JSON document, hot-swap it at runtime, and get a verifiable receipt for every decision. MAP is released and available on npm. The TypeScript SDK is the reference implementation; Python and Go SDKs are in preview and not yet contract-aligned. MAP records tamper-evident audit artifacts that may support regulatory audit-trail requirements, but it is not itself a compliance certification.

Fig. 2 · Protocol sequence

Illustrative

  1. 1Agent → MAPDispatchRequest · payment.execute $5,000
  2. 2MAPevaluate policy · payment.* amount_gt 1000 · ~1 µs (synthetic)
  3. 3MAP → Human approverrequire approval · execution stops · approval_reference
  4. 4Human approver → MAPapprove() · or approve via webhook
  5. 5MAP → Adapterexecute · payments adapter
  6. 6MAPsign and log receipt · typ MAPSIG

Dispatch, policy, decision, receipt: one gated payment from the §11 example, traced through the protocol.

1.1Problem statement

  1. 1.1.1No gate. Agents fire payments, database writes, and deployments with nothing checking policy first.
  2. 1.1.2No audit trail. Decisions live in memory and vanish with the process: there is nothing to show an auditor.
  3. 1.1.3Approvals are bolt-on scripts. Human-in-the-loop is hand-rolled per project instead of being part of the protocol.

1.2Capabilities

  1. 1.2.1Runtime policy engine with hot-swap capabilities
  2. 1.2.2Cryptographically signed receipts (HS256/RS256 JWS, typ MAPSIG) with operator-managed keys
  3. 1.2.3Human-in-the-loop approval workflows via webhooks
  4. 1.2.4TypeScript SDK (reference); Python and Go SDKs in preview
  5. 1.2.5Built-in adapters for HTTP, payments, and database reads
  6. 1.2.6Conformance program defined with reference profiles

1.3Applicability

  1. 1.3.1Gate AI payments, database writes, and infrastructure changes
  2. 1.3.2Route high-risk agent actions to human approval workflows
  3. 1.3.3Produce audit trails and signed receipts for regulated systems
  4. 1.3.4Deploy as an HTTP gateway with policy and audit endpoints

§2 · Dispatch requests

Every action arrives as a request.

An agent attempts to execute a consequential command. MAP receives the dispatch: a capability plus its TaskEnvelope. map() wraps your agent with SimpleRule policy, and every action is a DispatchRequest: task_id, requester_identity, intent, risk_class.

Record 2.1 · An agent request (DispatchRequest)

capability
npm.publish
task_id
task-001
requester_identity
service · cli-agent-01
target_agent
release-agent-v1
intent
Publish the package
risk_class
medium
delegation_token
carried in the envelope

The capability travels with its task envelope: who is asking, which agent acts, why, and at what risk.

§3 · Policy

Policy is a JSON document.

Policy is declared as a JSON document. MAP intercepts each action and evaluates it against the policy rules in-process, using the SimpleRule DSL.

3.1Hot-swap

The policy document can be hot-swapped at runtime. A swap measures at about 6 µs (see §8).

Record 3.1 · A SimpleRule policy rule

When
The capability is npm.publish
Require
Human approval

policy → policy′ · hot-swap · ~6 µs

§4 · Decisions and human approval

Allow. Require approval. Deny.

A dispatch resolves to one of three outcomes. Each path logs a signed receipt (§5).

4.1Human approval webhooks

Human-in-the-loop approval is part of the protocol rather than a per-project script. High-risk actions are routed to an approval workflow via webhooks; the onApprovalRequired handler receives the capability and an approve() callback (see §11).

Table 4.1 · Decision paths

OutcomeBehaviour
allowPolicy passes: execution proceeds through the built-in adapters: HTTP, payments, db.read.
require approvalExecution stops with an approval_reference; humans approve via webhook or .approve().
denyBlocked immediately: nothing executes, and the denial is logged.

A DispatchRequest (capability + envelope) is evaluated by SimpleRule policy. Three outcomes, one destination: every path ends in a signed receipt.

§5 · Signed receipts

Every path ends in a signed receipt.

A deterministic receipt is generated, signed, and logged for every path: allow, approval and deny. Receipts are signed as HS256/RS256 JWS with typ MAPSIG, using operator-managed keys, and are tamper-evident.

Wire formats verified against micro-agent-protocol: src/protocol, src/map.ts, schemas/. Key handling is described in the Signing Model.

Fig. 3Signed receipt

5.1Receipt fields

Receipt fields with example values
FieldExample value
receipt_id"receipt:task-001:0"
task_id"task-001"
agent_id"release-agent-v1"
action_taken"npm.publish"
resource_touched"npm registry"
policy_checks["strict-release-gate"]
approval_used"approval_998"
timestamp"2026-03-19T17:55:10Z"
result_hash"sha256:..."
signature"eyJhbGciOiJIUzI1NiIs..." · HS256 / RS256 JWS

§6 · Adapters

Allowed actions run through adapters.

When a decision is allow, execution proceeds through MAP's built-in adapters. MAP can also be deployed as an HTTP gateway with policy and audit endpoints.

  1. 6.1HTTP
  2. 6.2Payments
  3. 6.3Database reads db.read

§7 · SDKs

One reference. Two previews.

The TypeScript SDK is the reference implementation. Python and Go SDKs are in preview and not yet contract-aligned. Coverage is measured against a 15-surface matrix.

Table 7.1 · SDK status and surface coverage

LanguagePackageStatusSurface coverage
TypeScript@sidianlabs/mapReleasedReference implementation13/15 · 87%
PythonmapprotocolPreviewNot yet contract-aligned12/15 · 80%
GomapprotoPreviewNot yet contract-aligned9/15 · 60%

§8 · Performance

Sub-millisecond policy evaluation.

Policy evaluation is sub-millisecond. MAP adds essentially zero overhead next to the AI call it gates.

Methodology and reproducibility notes: Benchmarks and the lab's benchmarks page.

Table 8.1 · Policy evaluation latency

OperationLatencyThroughput
Policy eval · 5 rules~1 µs1.2M/sec (synthetic)
Policy eval · 100 rules~20 µs50K/sec
Full execution · no I/O~4 µs256K/sec
Policy hot-swap~6 µsinstant

§9 · Conformance

Defined. Not yet certified.

No implementations certified

Current status. The conformance program is defined, but no implementations have yet been certified.

The program defines three levels with reference profiles. Certifications are valid for 12 months.

  1. 9.1Level 1: Protocol Compliant. Basic schema correctness plus the dispatch and approval flow. The entry bar for any MAP implementation.
  2. 9.2Level 2: Security Verified. Signing, replay protection, and tenant isolation. Cross-tenant access denial must be demonstrated, not claimed.
  3. 9.3Level 3: Production Ready. Reliability, chaos engineering, disaster recovery drills, and a 30-day production stability report.

§10 · Interoperability

Composes with the protocols you run.

MAP is designed to compose with, not replace, the protocols you already run.

ProtocolRelationship
MCPTool connectivity: MAP wraps MCP tools with policy enforcement.
A2AAgent-to-agent tasks: MAP governs execution within A2A task flows.
ACPCommerce and payments: MAP provides the policy layer for ACP payment flows.

§11 · Installation

One install. One map() call.

Install the package from npm, wrap your agent in one map() call, and your agent is gated. The install guide walks through it step by step.

That's it. No TaskEnvelope. No AgentDescriptor. No DelegationToken. Just policy, handlers, and receipts. Every decision your agent makes now gets a cryptographically signed receipt.

Before
AI agent runs payment.execute for $5,000. Nothing stops it. No record. No approval.
After
Same action. MAP checks policy in ~1 µs (synthetic), pings your Slack, and only executes on approval, with a signed receipt.
You wrote
Six lines of policy. Zero infrastructure. Install from npm and go.

Table 11.1 · Gating an agent: the policy you write

WhenConditionDecision
payment.*amount over $1,000Payments over $1,000 need a human.require approval
db.writeenv is productionBlock writes to production.deny
* (anything else)noneEverything else proceeds.allow

When a rule requires approval, your approval handler receives the capability and an approve() callback: ping Slack, wait for the human, and approve. Your agent is otherwise unchanged.

Read the docs npm

§12 · Scope and compliance

What MAP governs, and what it does not.

  1. 12.1MAP governs registered agent actions. It records tamper-evident audit artifacts that may support regulatory audit-trail requirements, but it is not itself a compliance certification.
  2. 12.2The Python and Go SDKs are in preview and not yet contract-aligned with the TypeScript reference. No implementation has yet been certified under the conformance program.
  3. 12.3What MAP does not guarantee is written down in Non-Guarantees; see also the lab's non-guarantees and claims & evidence.

§13 · References

Read the source.

Claims, benchmarks, non-guarantees and the changelog, alongside the repository and documentation.