Scope

SCOPE solves the authorization gap in blockchain: turning wallet-level permission into programmable, enforceable transaction-level authority for autonomous agents.

Comment

SCOPE — The Execution Firewall for Autonomous Agents

The Blockchain Problem

Blockchains are very good at answering one authorization question:

“Was this transaction authorized by the key that controls the account?”

But autonomous agents introduce a more granular problem.

An agent may legitimately be authorized to act on behalf of a user, protocol, or organization without being authorized to perform every transaction that its wallet can technically execute.

A procurement agent may need permission to pay suppliers—but not arbitrary addresses.

A trading agent may need permission to trade—but only within defined assets, limits, and time windows.

A service agent may need access to funds—but only for a specific economic purpose.

Traditional cryptographic authorization establishes control over an account. It does not, by itself, express the full economic boundary within which an autonomous agent is allowed to operate.

This creates a fundamental blockchain problem:

«How do we give an autonomous agent useful execution authority without giving it unrestricted authority over the assets it controls?»

This problem becomes increasingly important as blockchain wallets evolve from passive accounts into programmable economic actors. Ethereum's current agent ecosystem already points toward smart accounts, spending limits, session keys, and granular permissions as mechanisms for constraining autonomous execution.

Our Solution

SCOPE is an onchain execution firewall for autonomous agents.

Instead of trying to control what an AI thinks, SCOPE controls what its authorized execution layer is actually permitted to execute.

Developers define machine-enforceable execution policies covering:

  • WHO — which agent is authorized
  • WHAT — which assets/actions are permitted
  • WHERE — which recipients or contracts are permitted
  • HOW MUCH — per-transaction and spending limits
  • WHEN — validity and execution windows
  • UNDER WHAT CONDITIONS — verifiable execution requirements where applicable

The policy is registered onchain.

When the agent requests an execution, SCOPE validates the request against that policy before the underlying blockchain action is executed.

If the request satisfies the policy, execution proceeds.

If it violates the policy, the smart contract rejects the execution.

The core model

AI decides → SCOPE authorizes → Blockchain executes

The AI remains responsible for making the decision.

SCOPE is responsible for determining whether that decision falls within the authority that was granted to the agent.

A Concrete Example

Consider an autonomous procurement agent named Atlas.

Atlas is authorized to spend:

  • Up to 500 USDC per transaction
  • Only with approved supplier addresses
  • Only using an approved asset
  • Only during a defined validity period
  • Only when the request is authorized by the registered agent

A legitimate payment of 500 USDC to an approved supplier satisfies the policy and succeeds.

Now suppose the agent's execution layer is compromised.

It attempts to send 480 USDC to an attacker-controlled address.

The signature may still be valid.

The agent may still be the correct agent.

But the requested recipient is outside the authority defined by the policy.

SCOPE rejects the execution.

The transaction does not simply display a warning in the dashboard—the enforcement occurs in the smart contract execution path.

The same mechanism can reject an otherwise authorized action when the amount exceeds the policy's limit or another required constraint is violated.

«The AI made the decision. SCOPE enforced the boundary.»

What We Built

SCOPE separates decision authority from execution authority.

The core system consists of an onchain policy registry and an execution contract.

"ScopePolicyRegistry"

Stores and manages the execution policies associated with agents.

A policy can define parameters such as:

  • Authorized agent
  • Allowed assets
  • Approved recipients
  • Maximum amount per action
  • Spending limits
  • Validity period
  • Additional execution constraints

"ScopeExecutor"

Acts as the enforcement boundary.

Before dispatching an action, it validates the execution request against the registered policy.

The execution path incorporates:

  • Agent authorization
  • Asset restrictions
  • Recipient/target restrictions
  • Amount limits
  • Deadlines
  • Nonces
  • Chain context
  • Verifying-contract context
  • Atomic execution

Execution requests use typed cryptographic authorization so that an authorization is bound to the intended execution context rather than being treated as a generic reusable signature.

This follows an important principle in smart-account authorization: execution authorization must be bound to its context, with mechanisms such as chain ID, contract/domain context, nonce, and validity windows helping prevent replay or cross-context reuse.

Demonstration Contracts

We built a complete test environment around the enforcement layer:

  • MockUSDC — test asset
  • SafeMerchant — authorized recipient
  • MaliciousMerchant — unauthorized recipient used to demonstrate enforcement

This allows the same execution path to demonstrate both successful and rejected transactions.

Why This Needs Blockchain

SCOPE is not simply a dashboard that records what an agent is supposed to do.

The critical property is that the policy exists in the execution path.

A conventional application could display:

«“Agent limit: 500 USDC”»

while the underlying wallet still possesses the ability to transfer 10,000 USDC.

That is not an execution boundary.

With SCOPE, the relevant policy is checked by the smart-contract layer before the protected action is executed.

A violating request therefore reaches an actual blockchain-enforced boundary.

This is the distinction between:

Policy as information

and

Policy as enforcement.

Smart contracts already provide the primitive required for this model: state-changing operations can be guarded with conditions that cause execution to revert when those conditions are not satisfied.

How SCOPE Differs From Simply Giving an Agent a Wallet

A private key answers:

«“Who can authorize this account?”»

SCOPE asks an additional question:

«“What is this authorized actor allowed to execute?”»

This creates a separation between:

Identity

The agent is cryptographically identified and authorized.

Authority

The agent is constrained by an explicit execution policy.

Execution

The blockchain only receives the protected action after the policy has been satisfied.

This distinction is particularly important for autonomous systems because an agent can be correctly authenticated while still producing an economically unacceptable action.

Technical Architecture

             AUTONOMOUS AGENT
                    │
                    │ Execution Request
                    ▼
          ┌────────────────────┐
          │   SCOPE EXECUTOR   │
          │                    │
          │ Agent verification │
          │ Asset check        │
          │ Target check       │
          │ Amount check       │
          │ Deadline check     │
          │ Nonce check        │
          │ Context binding    │
          └─────────┬──────────┘
                    │
             Policy satisfied?
                /          \
              NO            YES
              │              │
              ▼              ▼
           REVERT       Execute action
                             │
                             ▼
                     BLOCKCHAIN STATE

The architecture is intentionally designed so that the AI does not become the final authority over asset movement.

The agent proposes an action.

SCOPE determines whether that action falls within its delegated authority.

The blockchain executes only after the enforcement layer accepts it.

Security Model

SCOPE's execution authorization incorporates multiple dimensions rather than relying on a single spending cap.

Agent binding

An execution request must correspond to the authorized agent.

Target restrictions

Policies can restrict which recipients or contracts an agent can interact with.

Asset restrictions

Policies can constrain which assets can be used.

Amount restrictions

Execution can be bounded by per-action and spending limits.

Temporal restrictions

Policies can contain validity/deadline constraints.

Replay protection

Execution requests incorporate nonces and contextual information to prevent an authorization from simply being reused.

Atomic enforcement

A policy violation causes the protected execution path to revert rather than merely producing an offchain warning.

The Prototype

We built a working web application around the enforcement layer.

The dashboard provides interfaces for:

  • Agent management
  • Policy creation
  • Policy inspection
  • Execution simulation
  • Policy testing
  • Execution history
  • Violations
  • Smart-contract information
  • Developer integration

The most important part of the prototype, however, is not the dashboard.

It is the enforcement path behind it.

The demonstration shows:

  1. Authorized execution

Atlas attempts to pay an approved supplier within its policy.

Result: SUCCESS

  1. Unauthorized recipient

Atlas attempts to send funds to an address outside the approved recipient set.

Result: REVERTED

  1. Excessive amount

Atlas attempts to exceed its permitted transaction amount.

Result: REVERTED

The same interface therefore demonstrates both sides of the execution boundary: permitted actions and cryptographically authorized but policy-invalid actions.

Challenges

The central engineering challenge was ensuring that the security model was actually enforceable.

It would have been significantly easier to create a dashboard that displayed spending limits and visually marked transactions as safe or unsafe.

That would not solve the underlying blockchain problem.

We instead designed the execution flow so that policy validation occurs inside the smart-contract-controlled path.

This required us to reason about:

  • Policy storage
  • Agent authorization
  • Typed execution requests
  • Nonces
  • Deadlines
  • Chain context
  • Contract-domain binding
  • Target and asset restrictions
  • Atomic execution and reverts

The result is a system where the policy is not merely a statement about what an agent should do.

It becomes a constraint on what the execution layer can actually perform.

What We Learned

The most important insight from building SCOPE was that autonomy and unrestricted authority are not the same thing.

An autonomous agent can make decisions independently while operating inside a bounded execution space.

This is already reflected in the direction of Ethereum's account-abstraction ecosystem, where smart accounts and modular account systems enable mechanisms such as spending limits, session keys, and granular permissions.

SCOPE explores a dedicated execution-policy layer for that problem.

Instead of asking:

«“How do we make the AI trustworthy enough to control the wallet?”»

we ask:

«“How do we make the wallet incapable of executing actions outside the authority granted to the AI?”»

That is the foundation of SCOPE.

Future Scope

SCOPE is currently a prototype of the execution-policy layer.

Future development could extend the system toward:

  • ERC-4337 smart-account integration
  • Session-key based agent delegation
  • More expressive contract/action policies
  • Multi-chain policy enforcement
  • Conditional or postcondition-based execution
  • Human escalation for high-risk actions
  • Agent reputation and identity systems
  • Developer SDK/API integrations
  • Policy modules that can plug into existing smart-account infrastructure

These directions build on existing Ethereum account-abstraction and agent-authorization work rather than attempting to replace it.

Why SCOPE

Autonomous agents are becoming economic actors.

They will pay for services, interact with protocols, trade assets, and coordinate with other agents.

The fundamental infrastructure question is therefore not only:

“Can an agent sign a transaction?”

It is:

“Can we define exactly what that agent is authorized to execute—and enforce that boundary onchain?”

SCOPE is our answer:

«Give agents autonomy without giving them unlimited execution authority.»

AI decides. SCOPE enforces. The blockchain settles.

Built With

Share this project:

Updates

Submission history