Skip to main content
CUSTOMER-OWNED AUTHORITY FOR AI AGENTS

Your AI can act. Map both sides first.

Authority Brain maps what the agent declares it can reach and where evidence should return. You decide which actions need authority. At a completely mediated executor, Gate checks the exact mandate before the action and binds authenticated outcome evidence afterward.

Two eyes. One before the action. One after.
Watch the Gate decide Scan my agent locally
Authority Brain proposes. The customer decides. Gate enforces.
Two-sided visibilityIllustrative
What the agent can reachMove moneyDeploy codeDelete data
EMILIA Authority BrainTwo eyes connected by a synaptic brain illustrate declared agent actions on the left and expected protected-outcome evidence on the right. The owner decides what requires authority and Gate enforces separately.INTENTOUTCOMEGATE
What happens nextExact authorityProvider entryOutcome evidence
Authority Brainmaps and proposes
Customer ownerdecides
Gateenforces
01 / Discover / illustrative workflow

A routine email asks to change a vendor bank account before the next payment.

The agent has a valid identity and working credentials. Neither fact establishes that this exact destination change is inside the customer's authority.

vendor.bank_account.updateThe scan finds vendor.bank_account.update and proposes it for owner review before the next payment workflow is protected.Illustrative workflow, not a customer claim.
A four-step path

See it. Decide it. Protect it. Prove it.

Authority Brain never turns visibility into permission. The owner sets the rule, and a real Gate at the executor boundary puts it into force.

  1. 01

    See

    Find the declared MCP and OpenAPI actions the local scanner can actually see.

  2. 02

    Decide

    Review the proposed consequence, exact fields, confidence, and blind spots. The owner decides what needs authority.

  3. 03

    Protect

    For a reviewed MCP action, put Gate at the credential-owning executor boundary before the action runs.

  4. 04

    Prove

    Refuse insufficient authority, consume accepted authority once, and keep a portable record under customer-pinned rules.

SYNTHETIC LOCAL DEMO

Actions your agent says it can take

Choose an action to see what the owner would need to decide. These are fictional examples. This page has not scanned your device, connected to your systems, blocked production, or detected fraud.

Browser-only simulation · no external effect
Actions found4fictional records
Needs a decision3owner decides
Read-only candidates1proposal only
Paths not visible1unknown stays unknown
02 / Inspect proposal

Release wire transfer

Needs a decision

Moves funds to an externally controlled beneficiary account.

Authority source
Not established by static scan — owner review required
Assurance
Proposed receipt · class_a
Category
money_movement.release
Confidence
medium
Required exact fields
action_typeamount_usdcurrencypayment_instruction_idbeneficiary_account_hash
Named blind spots
  • Direct provider API paths and alternative payment rails are not visible in this declaration.
  • Whether production credentials are isolated behind Gate is not established by a scan.
03 / Synthetic proof path

From proposal to portable evidence

Step 1 of 6: Scan proposal. The synthetic declaration produced a proposed disposition and named its blind spots.

  1. 01
    Scan proposal

    The synthetic declaration produced a proposed disposition and named its blind spots.

  2. 02
    Human review

    A fictional owner accepts the material fields and required authority for this demonstration.

  3. 03
    Synthetic refusal

    A local mock call without authorization is refused before its supplied handler runs.

  4. 04
    Exact-action approval

    A synthetic approval artifact binds the selected action and exact field values.

  5. 05
    One-time execution

    In-memory demo authority is consumed once. No external provider or production system is touched.

  6. 06
    Portable evidence

    A synthetic evidence packet records the bounded demo result without claiming production enforcement.

Current synthetic stateScan proposal

The synthetic declaration produced a proposed disposition and named its blind spots.

Synthetic packet preview
{
  "artifact": "EP-SYNTHETIC-AUTHORITY-DEMO-v1",
  "selected_action": "releaseWire",
  "result": "pending",
  "handler_invoked_without_authority": false,
  "authority_consumed_once": false,
  "visitor_environment_scanned": false,
  "production_enforcement": false
}
This proves only the browser simulation shown here. Production prevention requires a completely mediated Gate, durable shared state, pinned trust roots, credential custody, and deployment-specific verification.
Deliberately bounded

The unknowns stay visible.

Authority Brain reduces the cost of finding and reviewing declared action surfaces. It does not turn incomplete visibility into a safety score.

What the local product can establish

  • Which supported declared actions were visible to this scan
  • Why a consequence classification was proposed
  • Which exact fields and authority sources require owner review
  • Whether a supported local synthetic refusal kept its mock handler from running

What remains a deployment question

  • Whether every consequential path reaches the same Gate
  • Whether provider credentials are unavailable through another path
  • Whether production state, keys, policy, and approvers are configured correctly
  • Whether external effects occurred beyond the evidence an observer can verify
Start with the free local product

Map one declared action surface.

The generated dashboard uses no account, upload, telemetry, or remote asset. When invoked through npx, npm may download the package before scanner startup. The scan itself launches no configured server.

TerminalLocal command
npx @emilia-protocol/scan brain ./tools.json
 
Open package Protect one workflow