AI agents · DeFi execution · Research concept
Agents can move funds. What should decide which moves are allowed?
SecureAgent is a research concept for a policy layer between an AI agent and the chain.
It explores how a transaction could be decoded, evaluated against policy, and allowed, held for review, or blocked.
SecureAgent is an exploratory research concept, not a product offering. We are speaking with teams building transaction-executing agents to understand their needs.
Concept scope
Illustrative protocol and transaction patterns used to explore the concept. These are not live integrations, partnerships, endorsements, or customer deployments.
- Batched transactionsIllustrative inner-call decoding
- ERC-4626 vaultsIllustrative deposit pattern
- AMM swapsIllustrative swap pattern
- ERC-20Illustrative approval pattern
- Chain agnosticModel works on decoded calldata
The stakes
An agent mistake is a settled transaction.
A hallucinated token address, a wrong recipient, a misread balance. In a chat window these are bad outputs and get corrected. Once the agent can sign, each one is an irreversible transfer.
The agent is a co-signer, never the key holder.
That part is already understood. In the illustrated model the policy layer would hold no key either. It would decide whether a call is permitted at all, before anyone signs.
The permission surface is where the risk now lives.
The set of things a co-signing agent may do is the attack surface. Most teams express it as a short allow-list and find the gaps in production.
Illustrative evaluation
Decoded before it is judged.
Static sample data shipped with this page. Nothing is evaluated live, no network calls, no transaction execution.
Vault deposit
Case 1 of 3Example chain · 0
A deposit into a permitted vault, with the receiver set to the operator's own account.
| chain | Example chain 0 |
|---|---|
| target | Permitted deposit vault0x2e8b5d41a09cf736b2d170e85a9c43f10d6b2a57on the allowed list |
| selector | deposit(uint256, |
| decoded arguments | |
| assets | uint2562,500.00 units |
| receiver | addressown smart accountmust be the operator's own account |
| value | 0 native |
| value (simulated) | within the configured size limit |
checks
- permitted actionpass
- expected
- the action is on the policy
- actual
- permitted
- destinationpass
- expected
- value returns to the operator's own account
- actual
- own account
- sizepass
- expected
- at or under the automatic limit
- actual
- under
- cumulative sizepass
- expected
- inside the rolling window
- actual
- inside
- verdict
- ALLOW
- rule that decided
every check passedA permitted action, a permitted destination, and a size inside the configured limits. It would go to the signer without anyone being asked.
What the concept explores
What SecureAgent does
Decode
Each call would be decoded to the function it actually calls and the arguments it carries, before being judged. Batched calls would be unwrapped and each inner call considered on its own, rather than judged by its envelope.
Decide
Rules rather than model judgement. Where value may go, which actions are permitted, how large they may be, and how much may accumulate. The aim is that the same input would always yield the same verdict.
Delegate
A call the rules mark for review would go to a named person. The approver would see the decoded call rather than raw calldata. The example assumes nothing would execute until they answer.
In the illustrated model the agent holds no key. It would still need a boundary.
The concept is a policy gate: a component that would sit between the agent and the signer, decide per call, and never sign. The walkthrough below is an illustration of that model, not a description of a running system.
Illustrative concept · static example
Request
The agent proposes a transaction: target contract, calldata, value. In the illustrated model it would hold at most a co-signer key, never a key that moves funds alone.
Step 1 of 4: Request
- 01Agent
- 02SecureAgent
- 03Policy evaluation
- 04Signer
In the illustrated model the policy layer would not hold a private key and would not sign. Nothing here is offered as software you can run today.
The model only holds if the gate is the only path.
An agent that can call a public RPC endpoint directly, or that holds a key able to sign alone, would not be behind the gate. Closing those paths would be part of any real deployment. This is an assumption of the design model being explored, not a guarantee about a live product.
Decode the inner call. Then decide.
A batched transaction can carry many calls in one envelope. From the outside, the envelope looks like a routine call to a known contract. What matters is inside. The walkthrough below is a static illustration.
Outer envelope
Batched transaction
An outer call to a batching contract that forwards several inner calls, value 0.
- to
- multi-send batching contractforwards the inner calls
- value
- 0 ETH
- selector
- batch(bytes)
- operation
- batchedone envelope, several calls
Known contract. No ETH. A routine batch. Judged by the envelope alone, this would look benign.
Inner calls, evaluated one by one
call 1Stablecoin0x4d2f1a7c9b3e05d86af41c7209b35e0d6ac1f842
approve(address,uint256)
- spender
- 0x2e8b…2a57on the allowed list
- amount
- 2,500.00 units
ALLOWpermitted approval
A bounded amount, to a spender on the allowed list.
call 2Permitted deposit vault0x2e8b5d41a09cf736b2d170e85a9c43f10d6b2a57
deposit(uint256,address)
- assets
- 2,500.00 units
- receiver
- own smart account
ALLOWpermitted deposit
Receiver is the operator's own account, and the size is inside the limit.
call 3Stablecoin0x4d2f1a7c9b3e05d86af41c7209b35e0d6ac1f842
transfer(address,uint256)
- to
- external addressnot a permitted destination
- amount
- 250,000.00 units
BLOCKdestination
Moves value to an address the policy does not allow. Nothing on the policy permits it, and the default is to refuse.
- call 1ALLOW
- call 2ALLOW
- call 3BLOCK
worst inner call
Call 3 fails. The whole batch is refused. Nothing in it executes.
In the illustrated model a batch would be judged by its worst inner call, never by its envelope.
The failure class this explores
Transaction-review failures can arise when a signer cannot clearly see the effective calls inside a complex transaction. The outer call looks routine while an inner call carries the real effect.
Decoding and evaluating each inner call before signing is the response this concept examines. It is not a guarantee against loss. The question we want to test with teams is whether a check of this shape would be useful in practice.
A policy gate is not a signer threshold.
Two different controls. Both matter. They answer different questions and this page keeps them apart. The diagrams below are illustrative.
The concept explores this.
Policy gate
Decides whether a call is permitted at all.
Would evaluate the decoded call against the policy: where it sends value, what it does, and how large it is. Output would be allow, hold, or block.
Your multisig is this.
Signer threshold
Decides how many keys must sign.
A 2-of-3 multisig needs two signatures. It does not inspect what is being signed. It is a quorum, not a judgement.
counts signatures, does not read the call
The concept would sit in front of a signer arrangement rather than replace one, and would not lower the threshold.
Allow, hold, block
Illustrative concept
- ALLOW
Allow
Every rule passes. The call could proceed to the signer. Nobody is asked.
- HOLD
Hold for approval
A rule marks the call for review, such as a size above the automatic limit. A named approver would see the decoded call and decide. The example assumes nothing would execute until they do.
- BLOCK
Block
A rule fails outright, so the call would be refused and the reason reported back to the agent rather than silently dropped.
Who would be asked, and when
| Condition | Verdict | Who decides |
|---|---|---|
| Inside every rule | ALLOW | Nobody. Automatic. |
| Above the automatic size limit, below the hard limit | HOLD | A named approver. |
| Outside a rule | BLOCK | Nobody. Refused, rule reported. |
| Cannot be decoded | BLOCK | Nobody. Fails closed. |
Policy example
Rules you can read.
In the model being explored a policy would be a file, not a prompt: a short, readable statement of where value may go, what the agent may do, and how large it may be before a person is asked.
Illustrative concept
A sketch of the shape a policy might take. There is no schema, no API and no implementation behind this example.
Illustrative concept. Static example, no live transaction execution.
# Illustrative sketch of what a policy might look like.# Not a schema. Field names and structure are for reading, not for building. # Where the agent may act.venues: - curated deposit vaults - approved swap venues - token approvals, bounded # Where value may end up.destinations: # Left empty, funds can only ever come back to the operator's own account. external: none # Which actions are permitted, named rather than enumerated by selector.actions: - deposit - withdraw - approve - swap # Anything not named here is refused. There is no default-allow. # How large, before a person is involved.size: per_transaction: automatic below a set figure review: above that figure, a named approver decides ceiling: above a hard figure, refused outright cumulative: a rolling total across a window # Approvals must be bounded to the transaction that needs them,# never open-ended.allowances: bounded # Who is asked when a call is held.approvers: - treasury-opsWhy a separate layer
You could build this yourself.
Most teams do, as an allow-list inside the agent. This is the hypothesis we want to test with you: what that approach gets you, what it may miss, and where a separate enforcement point would differ. It is a discussion framework, not a comparison against a shipping product.
| Dimension | An in-house allow-list | A separate policy-enforcement layer (concept) |
|---|---|---|
| What it checks | The target address. Sometimes the function name. | Would check the function and every decoded argument, per call. |
| Batched calls | The envelope. A Safe batch is one transaction to one contract. | Would unwrap each inner call and judge it on its own. |
| Limits | Usually one per-call cap. | Would bound single transactions, what accumulates over time, and what an approval can authorise. |
| Who it constrains | The agent's code path. An engineer with deploy access changes the list. | Would constrain any party operating the agent, independently of who runs it. |
| Failure mode | Shared with the agent. Same deploy, same bug surface. | Separate. A second layer with its own failure mode, which is the argument for defence in depth. |
| Verdict | Often a model call or an ad-hoc condition. | Rule-based and deterministic by design. The intent is that the same input yields the same verdict. |
What an in-house allow-list gets you
A fast first control that you fully understand. For one protocol and a small, trusted team, it may well be enough. The concept would not replace your own checks. It asks whether a second enforcement point, one that does not share their failure mode, would be worth the extra moving part. That is the question we would like your view on.
Who we want to learn from
Three kinds of team we would like to talk to.
We are not selling anything. We want to understand the controls you already have, the ones you wish you had, and whether a boundary of this shape would help or get in the way.
Agent platforms
Your end users run agents over their own funds. We would like to hear how you think about exposing permission configuration, and what your users actually ask for.
Treasury and yield automation
An agent moves funds between protocols. We would like to hear what bounds you place on destinations, protocols and size, and when a person needs to be in the loop.
Teams adding execution to an agent
Your agent already reads and reasons. We would like to hear how you are approaching its permission surface before it can sign anything.
Exploring deployment models
Where should the boundary sit?
We are researching which operational boundary would be useful for teams running transaction-executing agents: an in-environment policy component, a separate service, or another model. No deployment option is currently being offered.
An in-environment component
A policy component that would run beside the agent and the signer, inside the operator's own environment. Open question: whether teams would accept another component in that path.
A separate service
The same evaluation, operated outside the agent's environment. Open question: whether the independence would be worth the added dependency and trust assumption.
Neither of these is available. They are the options we are weighing, and we would like to know which boundary would fit how your systems are already arranged.
Research enquiry
Help us research the problem.
We are looking to speak with teams building or operating transaction-executing agents. Tell us about the permissions, controls, and review flows you need. We will use your submission only to respond to this research enquiry.
We use what you send to answer your enquiry and to inform our research. We will not add you to a mailing list. This site uses no cookies and no analytics.
Or emaililyes.jeridi@nethermind.io