Governed Tool
Invocation for
Autonomous Agents.
A Model Context Protocol server that turns tool calls into cryptographically authorized, verifiable actions.
AI agents connect via standard MCP (SSE + JSON-RPC 2.0) and invoke tools across the full AGTS stack — infrastructure, identity, governance, memory, billing, and orchestration. Every action is pre-authorized, signed, and anchored before execution.
{
"mcpServers": {
"agts": {
"url": "https://agts-mcp.obligationsign.com/mcp/sse",
"headers": {
"Authorization": "Bearer YOUR_TOKEN"
}
}
}
}
No SDK. No adapters. If it speaks MCP, it works.
01 — What This Actually Is
Not Just
Tool Calling.
Standard MCP servers expose tools. The Sovereign MCP Gateway governs them. This is not logging after the fact. This is authorization before side effects.
Every tool call passes five deterministic gates before execution.
Semantic validity, financial validity, operational safety, policy admission, and cryptographic finalization. Only an ADMIT verdict allows execution. REFUSE or REVIEW stops the action before any side-effect occurs.
Every authorization is cryptographically signed.
A signed commitment — canonical JSON envelope, hybrid Ed25519+SLH-DSA signature, SHA-256 hash. The commitment hash becomes the authorization token. No valid commitment, no execution.
Every commitment anchored in a transparency log.
Governance envelopes are submitted as Merkle leaves. Inclusion proofs are available for any commitment. The signed tree head provides a tamper-evident root. Auditors can independently verify every agent action ever authorized.
Execution cryptographically bound to authorization.
After the tool runs, the execution outcome is recorded and linked to the original authorization via commitment hash. Deviations between authorized and actual behavior are cryptographically recorded. The loop is closed.
MCP vs. Governed MCP
MCP stays the same. The control layer changes completely.
| Standard MCP | Sovereign MCP Gateway | |
|---|---|---|
| Authorization | API key / OAuth | Per-invocation governance decision |
| Decision | Binary access | ADMIT / REVIEW / REFUSE |
| Audit | Mutable logs | Signed + Merkle-anchored |
| Execution link | None | Cryptographically bound |
| Tool control | Open endpoints | Optional tool binding |
| Transport | MCP (SSE) | MCP (unchanged) |
02 — Governance Lifecycle
Four Steps.
Four Proofs.
Every tool call follows a deterministic, verifiable lifecycle. Each step produces a cryptographic artifact.
Agent declares intent and evidence.
{
"intent": "send quarterly report",
"action": "send_sovereign_mail",
"recipient": "cfo@acme.com"
}
Five-gate evaluation runs.
G1 Semantic validity · G2 Financial validity · G3 Operational safety · G4 Policy admission · G5 Cryptographic finalization
Output: ADMIT · REVIEW · REFUSE
Governance envelope signed.
Canonical governance envelope created. Signed with hybrid Ed25519+SLH-DSA. Hashed (SHA-256) to produce commitment_hash.
This hash becomes the authorization token.
Tool executes. Outcome recorded.
Tool executes with commitment. Execution outcome is recorded. Linked back to authorization. Authorization → Execution → Outcome — all cryptographically bound.
Independent Verification
Anyone can verify any action. Verification does not require trust in the platform.
GET /verify?commitment={hash}
Signed governance envelope
Gate results
Hybrid Ed25519+SLH-DSA signature
Merkle inclusion proof
Tree root hash
Auditors, customers, or regulators can independently prove: what was authorized, what was executed, and that it was not altered.
03 — The Agent Stack
One Gateway.
Six Layers. One System.
AI agents don't just need tools. They need a full operating environment: where they can act, identify themselves, store memory, coordinate work, manage cost, and be governed. Today, this stack is assembled from separate vendors. Each layer introduces integration overhead, reliability risk, and audit gaps.
Why this matters
Every additional system you integrate becomes a failure point. If each layer operates at 99% reliability: 2 layers = 98%, 4 layers = 96%, 6 layers = ~94%. And that's before governance, drift, or coordination failures.
Fragmented agent stacks degrade multiplicatively. The alternative is not "better tools." It's a unified execution surface.
Why this can't be bolted on
The differentiator isn't any single layer — identity, governance, memory, orchestration, billing and tool execution all exist as separate products elsewhere. The differentiator is the vertical cryptographic binding: one commitment_hash threads identity → governance verdict → tool execution → billing entry → Merkle leaf. Every action carries the same authorization token across every layer.
This isn't a feature an incumbent can add in a release cycle. Retrofitting commitments onto an existing fragmented stack requires re-architecting every layer to accept, validate, and persist them — from the auth tier down to the billing ledger. The only path is from the bottom up.
A category of one, today. The moat is the binding, not the parts.
Infrastructure & Runtime
Persistent, isolated execution — not ephemeral sandboxes. Durable Objects for agent state. Health monitoring and alerting. Distributed worker mesh.
Agents that persist, recover, and can be audited over time.
Identity & Communication
Agents need identity — not just API keys. Claw Passport (cryptographic identity). Encrypted mail and file exchange. Peer authentication and trust network.
Agents that can prove who they are and securely interact with others.
Governance & Trust
The control layer most stacks are missing. Five-gate deterministic evaluation. Hybrid-signed commitments (Ed25519+SLH-DSA). Merkle transparency log.
Every action is pre-authorized, recorded, and independently verifiable.
Sovereign Memory
A ledger, not a notebook. Every memory write is a signed leaf on the same transparency log as governance decisions. Newest-first retrieval by construction — partial views are refused, not faked. Preferences and approvals become a signed, versioned rulebook the agent is bound to across sessions.
Memory that proves itself. Rules that don't drift. Portable as a single sovereign bundle.
Billing & Metering
Autonomous systems need economic boundaries. Per-agent resource tracking. Budget enforcement and alerts. Governance-linked cost signals.
Agents that cannot silently overspend or drift without consequence.
Orchestration & Autonomy
The layer where real agent capability emerges. Sub-agent spawning. Delegation chains. Workflow templates. Result merging.
Agents that can decompose tasks, parallelize work, and coordinate execution.
What makes this different
Tools. Maybe memory. Maybe orchestration. But each piece is loosely connected, differently governed, and inconsistently observable. Six vendors, six APIs, six failure modes.
The same governance pipeline. The same identity model. The same proof system. The same execution lifecycle.
One gateway. One protocol. One audit trail.
Strategic reality
The agent stack will not stay fragmented. It will consolidate around platforms that provide execution, coordination, governance, and verification as a single system. The Sovereign MCP Gateway is not a tool layer. It is the execution surface of a governed agent system.
04 — Tool Registry
14 Modules.
222 Governed Tools.
Every tool is available via MCP's standard tools/call method. Write tools require governance commitments. Read tools pass through the pipeline for audit. One gateway, one governance pipeline, zero bypasses.
submit_governance
Submit evidence for five-gate evaluation. Returns ADMIT with a signed commitment hash, or REFUSE/REVIEW with gate failure details. The commitment hash authorizes downstream tool execution.
verify_commitment
Verify any commitment by hash or leaf hash. Returns the full governance envelope, gate results, hybrid signature, and Merkle inclusion proof from the transparency log.
report_execution
Close the authorization-execution loop. Report whether the action was executed, failed, or deviated from the original authorization. Linked to the commitment via hash.
send_sovereign_mail
Send a governed email with optional attachments. Governance pre-authorization required. Every sent message produces a Merkle leaf in the transparency log.
list_inbox
List inbox messages with pagination. Read-only — no governance commitment required. Returns message metadata, sender, subject, and timestamps.
read_message
Read a specific message by ID. Returns full message body, headers, attachments, and governance metadata. Read-only access.
lookup_recipient_keys
Look up a recipient's public keys from the key registry. Used for client-side encryption before sending. Returns ECDH P-384 public key and key fingerprint.
upload_file
Upload a file to governed encrypted storage. Supports base64 content or URL fetch. Client-side encryption with salt/IV metadata. Governance commitment required.
list_files
List files owned by the user. Returns file metadata, sizes, upload timestamps, and folder paths. Read-only access — no governance required.
download_file
Download a file by ID. Returns base64-encoded content with encryption metadata for client-side decryption. Read-only access.
share_file
Share a file with another user. Governance commitment required. Supports read/write permissions with ECDH key wrapping for zero-knowledge file sharing.
delete_file
Permanently delete a file. Governance commitment required. The deletion event is recorded in the transparency log — the absence of a file is provable.
create_tunnel
Create a governed VPN tunnel. Full attestation handshake with ECDH P-384 key exchange. Governance commitment required. Produces SESSION_BIRTH Merkle leaf.
tunnel_status
Check tunnel session status. Returns chain length, bytes transferred, DNS query count, duration, and current governance verdict. Read-only.
disconnect_tunnel
Gracefully disconnect a tunnel session. Governance commitment required. Produces SESSION_DEATH Merkle leaf with terminal chain hash and traffic totals.
dns_query
Perform a governed DNS query through the encrypted DoH proxy. Each query is hashed and appended to the session's DNS chain. Auditable query trail.
The full Autonomous SOC stack — findings triage, incident lifecycle, human approvals, on-call policy, canary controls, the Autonomous Action Manifest, tenant signing keys, detection rules, and Phase 13 signed compliance packs — exposed as MCP tools so any MCP-speaking agent can drive a governed security operations center end to end.
soc_list_findings
List detection findings with status/severity filters. Read-only triage view across the tenant's detection surface.
soc_promote_finding
Promote a finding to a full incident with severity assignment. Anchored as a transparency leaf upstream.
soc_transition_incident
Move an incident through its state machine (TRIAGE → CONTAIN → ERADICATE → RECOVER → FINALIZED) with mandatory writeups on close.
soc_create_approval
Open a human-in-the-loop approval request for a high-impact action. Pairs with soc_respond_approval to close the loop.
soc_set_manifest
Update the Autonomous Action Manifest — the per-tenant policy that decides which actions an agent may take autonomously vs. require approval.
soc_evaluate_manifest_action
Pre-flight an action against the manifest. Returns the verdict (allow / require_approval / deny) without executing.
soc_upsert_rule
Create or update a detection rule. Includes canary mode controls so new rules can be shadow-evaluated before going hot.
soc_tenant_sign_probe
Probe the tenant signing key — verifies the dedicated key is provisioned and able to produce a signature before downstream operations rely on it.
soc_generate_compliance_pack
Emit a signed DORA Art.18 / NIS2 Art.23 / SOC 2 CC7 compliance pack. Content-addressed, tenant-key-signed, anchored to the transparency log.
+ 21 more: incident notes, approval inspection, on-call policy get/set, escalation & incident-engine canaries, manifest read, tenant key inspection & canary status, rule listing, rules canary, suppressions, and compliance pack listing/retrieval (markdown-renderable).
05 — Architecture
Edge-Native.
Globally Distributed.
The MCP Gateway runs on edge workers with KV for commitment storage and object storage for governance artifacts. Service bindings connect to the full AGTS worker mesh: protocol, log, billing, monitor, mail, drive, and tunnel workers.
Server-Sent Events over HTTPS.
MCP clients connect to /mcp/sse for the event stream and send tool calls to /mcp/messages. Standard MCP SSE transport — any compliant client works without modification.
Worker-to-worker bindings.
Service bindings connect the MCP gateway to downstream workers with zero-latency RPC. Mail, drive, tunnel, protocol, log, billing, and monitor workers are bound at the edge. No public network hops between services.
Commitment store at the edge.
Governance commitments stored in edge KV for sub-millisecond lookup. Governance envelopes and artifacts archived in object storage. Both globally replicated. No central database bottleneck.
Every commitment signed at the edge.
Hybrid Ed25519+SLH-DSA signing — classical elliptic-curve speed with post-quantum hash-based backup. Keys stored as encrypted secrets. The Web Crypto API signs governance envelopes in the worker runtime — no external HSM call. Signature verification is public and stateless.
Merkle tree — append-only.
Governance envelopes are submitted as leaves to the AGTS log worker. The log maintains a Merkle hash tree with signed tree heads. Inclusion proofs are available for any leaf. The tree is append-only — history cannot be rewritten.
Public, stateless, instant.
Any commitment can be verified at /verify?commitment={hash}. Returns the governance envelope, signature, gate results, and Merkle proof. No authentication required. Verification is a public good.
06 — Verdicts
Every Tool Call Gets a Verdict.
Before It Executes.
The five-gate evaluator produces a deterministic verdict for every governance submission. The verdict determines whether the tool executes.
All five gates passed. A signed commitment is created with the governance envelope, hybrid Ed25519+SLH-DSA signature, and commitment hash. The tool is authorized to execute.
One or more gates flagged for human review. The tool does not execute. The agent receives the specific gate failures and can resubmit with additional evidence or escalate to a human operator.
One or more gates failed definitively. The tool does not execute. The refusal is recorded in the transparency log. The agent cannot bypass the verdict — the governance layer is not advisory.
Business Impact
AI Agents Need
Governance Infrastructure.
Article 14 requires human oversight of high-risk AI. The MCP gateway's REVIEW verdict enables human-in-the-loop governance. Every agent action is logged, signed, and auditable — the accountability infrastructure the regulation demands.
Financial institutions deploying AI agents need continuous accountability for autonomous operations. Governance commitments provide the cryptographic evidence trail DORA requires — not periodic audits, but per-action proofs.
SOC 2 requires demonstrable controls over processing integrity and confidentiality. The MCP gateway's five-gate evaluation, signed commitments, and Merkle-anchored audit trail satisfy these criteria with cryptographic rather than procedural evidence.
Connect any MCP-compatible agent to governed tools. No custom governance code required — the gateway handles pre-authorization, commitment signing, and audit. Your agent calls tools; the gateway proves what happened and why it was allowed.
Every agent action produces independently verifiable cryptographic evidence. Governance envelopes can be exported, audited, and submitted as compliance artifacts. The transparency log provides a tamper-evident record of every authorized and executed action.
Every Tool Call.
Every Commitment.
Independently Verifiable.
Connect your agent. Submit governance. Watch it gate, sign, execute, and anchor. 222 tools spanning the full REST surface and the Autonomous SOC. One governance layer. One transparency log.