Skip to main content
Use Case / AI and Agent Control

Trust-control layer between AI intent and execution

Agents can move money, modify data, and operate infrastructure through tools that were granted at connection time. EMILIA Gate adds a customer-owned decision at the exact-action boundary. On a completely mediated covered path, the action reaches the provider only with accepted authority and required evidence.

AI is one wedge. The broader category is exact-action authority control. EMILIA is infrastructure for buyer-selected workflows where a consequential action needs a decision at the executor boundary.
Request Pilot
Intent
The agent proposes one typed tool call
Gate
The customer policy admits or refuses provider entry
Receipt
Authorization, admission, and outcome remain distinct

The problem

Agent frameworks handle connection and tool discovery. A connection grant alone does not establish authority for every possible parameter set. Gate sits at a selected executor boundary and checks one exact call against the customer's current mandate and evidence policy.

PROBLEM 01
Agents moving from recommendation to action
Agents can now call tools, mutate data, and trigger workflows. A broad tool grant does not answer whether this exact consequential call is within the customer's current mandate.
PROBLEM 02
Connection permission is wider than action authority
A framework may authorize access to a payment tool while leaving amount, destination, purpose, and one-time use to application code. That is the action boundary Gate is designed to protect.
PROBLEM 03
Attribution can stop at the session
Many workflows can name the service or credential that connected without preserving the accepted authority, exact action, and outcome evidence for one consequential call.

How EMILIA helps

EMILIA is not an agent framework. It is an authority-control layer that can be integrated at a selected tool or system-of-record boundary. Protocol proves. Gate prevents on the completely mediated paths the customer configures.

Buyer-defined action classes
The buyer selects which tool calls are covered and which evidence each class needs. Read-only traffic can remain outside the protected boundary; consequential calls can require stronger authority.
Fresh approval only when policy requires it
A finite mandate can let agents work unattended. When current authority is missing, stale, exhausted, or wider than the request, Gate refuses or returns to the configured authority source.
Action-bound attribution evidence
Each protected action can preserve the presenting agent credential, accepted delegation evidence, exact action, policy, admission, and outcome as distinct records.
Control mapping, not automatic compliance
EMILIA evidence can support an organization's EU AI Act, NIST AI RMF, or internal-control assessment. The organization and its authorized reviewer decide whether the complete system meets a requirement.

How EMILIA enforces trust in agent workflows

Three protocol capabilities make EMILIA the control layer for agent-driven actions.

CAPABILITY 01
Delegated authority evidence
EMILIA can verify a pinned agent credential and delegation chain under the relying party's rules, then bind that evidence to one exact action. A machine credential is not proof of a human's civil identity, and human approval is required only when local policy says so.
CAPABILITY 02
Exact tool-use binding
An agent with access to a payment API can call any endpoint. EMILIA binds authorization to the exact tool call parameters: the specific API endpoint, the specific payload, the specific amount and destination. An approval to call transferFunds with $500 to Account A cannot be replayed for $5,000 to Account B.
CAPABILITY 03
Customer-owned admission policy
The buyer defines the protected action classes, accepted issuers, evidence requirements, limits, and exception path. On a completely mediated covered path, no accepted exact-action authority and required evidence means no provider entry.

Infrastructure, not an agent tool

EMILIA is designed as trust substrate for high-risk action enforcement. AI agent control is one application of this substrate, not its boundary. The same protocol primitives that enforce trust before agent actions also enforce trust before government disbursements, financial wire transfers, and enterprise privileged operations.

+Open adapters and reference integrations for multiple agent frameworks
+Protocol primitives for exact-action challenges, approval evidence, receipts, and remedies
+Buyer-authored action classes that separate uncovered read-only traffic from protected consequential operations
+Structured evidence and published mappings that can support regulatory and internal-control review
+Pinned agent and delegation evidence that makes accepted authority traceable without treating a credential as civil identity

What it looks like in code

At a configured tool boundary, Gate evaluates one exact action. A current finite mandate can authorize unattended work; fresh approver evidence is an exception path when the buyer's policy requires it.

The gate — same everywhere
const d = await guardAction({ action: 'payment.release', context });
if (d.deny)            throw new Error(d.reason);   // blocked outright
if (d.signoffRequired) await waitForApprover(d);    // enrolled credential signs
// ...otherwise proceed under the configured mandate and record the decision.
MCP server
Claude Desktop, Cursor, Cline
{ "command": "npx",
  "args": ["-y", "@emilia-protocol/mcp-server"] }
LangChain.js
wrap any irreversible tool
import { withGuard } from '@emilia-protocol/langchain';
const safe = withGuard(tool, { action: 'payment.release' });
CrewAI / AutoGen
Python — guard() decorator
@guard("payment.release", context_fn=..., fetch=post)
def wire_transfer(amount, destination): ...
Full quickstart →Framework examples →
AI / Agent Governance

Trust before high-risk action in AI and agent workflows

The protected-workflow pilot is available to agent framework teams, AI infrastructure providers, and enterprise AI teams that can name one consequential tool or executor boundary.

Request a pilot

$25K · 90 days · 1 protected workflow. Synthetic and read-only validation first; production only through a buyer-approved Gate boundary.