Skip to content

Instantly share code, notes, and snippets.

@Aboudjem
Created April 18, 2026 08:17
Show Gist options
  • Select an option

  • Save Aboudjem/1e0c1e28d62c7613b79560daf0661c0f to your computer and use it in GitHub Desktop.

Select an option

Save Aboudjem/1e0c1e28d62c7613b79560daf0661c0f to your computer and use it in GitHub Desktop.
Agent Authority Protocol — 4-function ERC for binding AI agents to their authorized principals

Agent Authority Protocol

A 4-function ERC for binding AI agents to their authorized principals.

The on-chain primitive that lets any contract ask: who is the human or entity behind this agent address?


The Problem

85,000+ AI agents are registered on-chain via ERC-8004. They trade tokens, manage portfolios, execute DeFi strategies, participate in agent-to-agent commerce. But every permissioned token they touch breaks.

Concrete scenario:

  1. Alice is KYC'd on a security token (ERC-3643)
  2. Alice authorizes her trading agent to manage her position
  3. Agent calls token.transfer(bob, 100)
  4. Token checks isVerified(msg.sender)
  5. msg.sender is the agent address, not Alice
  6. Transfer fails. Compliance blocks the agent. Alice's authorized intent is invisible.

Same problem hits ERC-7943 (uRWA), ERC-8183 (Agentic Commerce), Aave Horizon liquidation bots, Sky's RWA agent program, custodial omnibus wallets, DEX routers on permissioned tokens, AA bundlers, multisig treasuries. The list is long and growing.


Why Existing Standards Don't Solve It

Standard Why it falls short
ERC-4337 / 7702 (smart accounts) Works when agent is a signer on the principal's account. Doesn't work when agent needs an independent wallet for liability isolation, audit separation, or cross-protocol portability
ERC-5639 (delegate.cash) Returns bool, not the principal address. Vault-keyed, not address-keyed. Compliance protocols can't pass the result into existing isVerified() checks
ERC-8004 Identity primitive. Tells you what the agent IS. Doesn't answer who AUTHORIZED it
ERC-8118 Function-level scope (what can the agent do). Doesn't bind agent to principal

There is no on-chain primitive today that any contract can call to resolve an agent address to its principal in one line.


The Proposed Standard

interface IAgentAuthority {
    function authorize(
        address agent,
        uint64 expiry,
        bytes calldata metadata,
        uint256 deadline,
        bytes calldata agentSignature
    ) external;

    function revoke(address agent) external;

    function principalOf(address account) external view returns (address principal);

    function getAuthority(address agent) external view returns (
        address principal,
        uint64 expiry,
        bytes memory metadata,
        uint64 authorizedAt,
        bool active
    );
}

4 functions. No fluff.

The killer feature

principalOf(addr) returns the principal for an authorized agent, and returns the input address itself for non-agents. This makes integration zero-branching:

// Before
function canTransfer(address from, address to, uint256 amount) external view returns (bool) {
    if (!isVerified(from)) return false;
    if (!isVerified(to)) return false;
    return _checkRules(from, to, amount);
}

// After (1 line per address, no branching)
function canTransfer(address from, address to, uint256 amount) external view returns (bool) {
    address effectiveFrom = authority.principalOf(from);
    address effectiveTo = authority.principalOf(to);
    if (!isVerified(effectiveFrom)) return false;
    if (!isVerified(effectiveTo)) return false;
    return _checkRules(effectiveFrom, effectiveTo, amount);
}

Works for agents AND direct wallets. No if statements. No conditional logic. The same function handles both paths.

Anti-squatting via EIP-712

authorize requires an EIP-712 signature from the agent confirming consent. Prevents anyone from registering a victim's address. ERC-1271 supported for smart contract agents.

One agent, one principal

Deterministic resolution. Multi-principal agents can deploy multiple agent addresses (cleaner audit trail anyway).


Why This Matters Now

  • Sumsub launched Know-Your-Agent (Jan 29, 2026): the off-chain binding exists, the on-chain anchor doesn't
  • Sky voted in 10 RWA agents (Feb 26, 2026): live agents, live compliance gap, $billions at stake
  • NIST AI Agent Standards Initiative (Feb 2026): federal framing of identification + authorization + delegation as required pillars
  • Coinbase + World Proof-of-Human + AgentKit (Mar 17, 2026): identity solved at on-ramp, downstream gap is exactly this primitive
  • Brickken ERC-8226 Regulated Agent Mandate (Apr 12, 2026): vendor-built compliance layer that needs an authority primitive at its base
  • ZeroID open-source agent identity launch (Apr 13, 2026): adjacent infra moving fast, the standard slot is open NOW

What an Integrator Commitment Looks Like

You don't need to ship anything before the Magicians thread goes live. The ask is simple:

  • Allow your name in the post as launch integrator
  • Public quote (1-2 sentences) on intent to evaluate or adopt
  • Optional: co-author credit on the EIP if your team contributes review

This signals to the EIP editors and the wider ecosystem that the standard has real-world demand, not a vanity draft.


Reference Implementation

Solidity reference impl with 8 test cases ready, deployable on Sepolia. Will be linked in the Magicians thread alongside the PR on ethereum/ERCs.


Feedback Wanted

  • Does the 4-function surface match your integration model?
  • Is the metadata extension hook flexible enough for your scoping needs?
  • What's missing for your use case?
  • Are you willing to be named as a launch integrator?

Reply here, on Magicians (link forthcoming), or DM me directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment