One line of code between your agent and a catastrophe.
Your AI agent can move money, delete production data, send email, and sign contracts. Agent Guard puts EMILIA Gate before the configured tool or executor, then requires the evidence your policy names. It protects only the paths actually mediated by that integration.
Coming from Scan? Start with one flagged tool.
Scan's protect output is a reviewable protection scaffold, not a patch. Review the generated files, bind the real executor path, configure durable consumption and provenance, then test the integration.
Run the rail now: FAST=1 node examples/mcp/payment-server.mjs · no account needed
Wrap the dangerous action. Ship the same day.
No proxy to deploy. No data path to reroute. You call the gate at the decision point; EMILIA answers allow, require signoff, or deny — under the policy and trust inputs configured for that mediated path.
The HTTP call below is live with your API key (signup is free). The wrapper below it ships today on npm and PyPI. Exact signatures in the docs.
# Ask EMILIA whether this exact action may proceed — before it runs.
curl -s https://www.emiliaprotocol.ai/api/trust/gate \
-H 'authorization: Bearer ep_live_…' \
-H 'content-type: application/json' \
-d '{
"entity_id": "agent_invoice_bot",
"action": "payment.release",
"context": { "amount": 50000, "destination": "acct_9f12" }
}'
# → { "decision": "allow" | "deny", "reasons": [ … ] }
# Signoff-grade decisions (allow_with_signoff) come from the
# /api/v1 precheck adapters — the full ceremony is on /finguard.import { requireReceiptForLangChainTool } from '@emilia-protocol/langchain';
// Wrap anything irreversible. Complete arguments are bound automatically.
const guarded = requireReceiptForLangChainTool(wireMoney, {
action: 'payment.release',
trustedKeys: [process.env.EMILIA_ISSUER_PUBKEY],
store: durableAtomicReceiptStore,
});
await guarded.invoke(
{ amount: 50000, to: 'acct_9f12' },
{ configurable: { emiliaReceipt: exactActionReceipt } },
);
// Missing, wrong-call, forged, or replayed receipt → tool never runs.
// Python: langchain-emilia consumes before effect and attests after.import { requireEmiliaReceipt } from '@emilia-protocol/require-receipt';
// Refuse the irreversible action unless a valid, action-bound receipt
// from a trusted issuer rides with the request.
app.post('/release-payment', requireEmiliaReceipt({
trustedKeys: [process.env.EMILIA_ISSUER_PUBKEY],
action: 'payment.release',
statusCode: 428,
manifestUrl: '/.well-known/agent-action-control.json',
authorization: {
authorization_endpoint: 'https://approve.example.com/api/v1/approvals',
flow: 'EP-APPROVAL-v1',
},
requiredFields: ['action_type', 'amount', 'currency', 'beneficiary_account_hash', 'action_caid'],
caidSelector: { field: 'action_caid' },
maxAgeSec: 900,
}), handler);
// No receipt? The caller gets 428 Receipt Required with a
// challenge; a well-behaved agent obtains one and retries. Verified
// offline — no EMILIA backend. Run: FAST=1 node examples/mcp/payment-server.mjsNo receipt, no irreversible action.
The flip side of the gate: make your own endpoint require named evidence. An irreversible call with no valid receipt gets a 428 describing exactly what to bring — a well-behaved agent obtains one and retries, and you verify it offline. The agent follows a pinned acquisition endpoint, a named human reviews the exact action, and the agent retries without a human operating the integration or support loop.
Add Receipt Required to an MCP server →Intercept, decide, record.
Your agent is about to do something it can’t take back. One receipt-required wrapper binds the complete executor input before it touches the real world.
The configured policy returns allow, require signoff, or deny. Allow means the stated policy was satisfied; it is not a claim that the action is wise, safe, or lawful.
When the configured evidence profile emits a signed decision, it binds the stated action bytes. A relying party can verify those bytes offline with @emilia-protocol/verify under explicitly pinned trust inputs. A signature verifies those bytes under the pinned key; it does not prove identity, authority, due process, or correctness.
If your agent calls tools, EMILIA can guard them.
Agent Guard is framework-agnostic middleware, not a lock-in. It sits at the action boundary, wherever that is in your loop — and it doesn’t care whose model your agent runs on.
Four things you never want an agent to do unsupervised.
Agent tries to wire $50K
An invoice-paying agent attempts a payment to a new account. The configured path blocks until the required exact-action evidence validates. Provider execution and outcome remain separate facts.
Agent tries to drop prod
A coding agent runs a destructive migration on the production database. The action is gated before it executes.
Agent redirects a benefit
An agent changes the bank account on a benefits case. The configured path can block for a caseworker decision and record the exact action. That record supports review; it does not prove due process, identity, authority, or correctness.
Agent exfiltrates PII
An agent attempts to export a table of personal records to an external destination. The high-risk write is intercepted.