A CODESPECT case study on building a trust framework for DeFi agents.
Autonomous yield agents are already working in production. They allocate stablecoin capital across protocols such as Aave, Morpho and Compound, react quickly to on-chain events, and can move capital without waiting for human intervention. Over the past year, several of them avoided incidents that hit passive positions holding the same assets. The bigger open question is no longer whether the technology works, but whether users and allocators can trust it.
Today, there is no common standard for comparing the security and risk profile of one agent against another, so every allocator has to build its own internal process. For retail users, this is inconvenient. For wallets, neobanks and institutional desks, it can become a blocker: a risk committee cannot approve exposure to a system if its security properties cannot be clearly described and compared.
Owney created the Agent Trust Framework to address this problem and invited external contributors to help shape it. CODESPECT was a key contributor from the security and risk perspective, with Core3 and Hacken also contributing to the framework. The framework is published at risk.owney.app, and the reasoning behind it is set out in the industry paper. It evaluates agents across three categories and thirteen sub-criteria.
This article covers some of the main design questions we worked through while contributing to the framework, and what they mean for teams building DeFi agents that may eventually be assessed against it.
An agent's risk is mostly not in its contracts
We approached the framework from our background in smart-contract security, and one thing became clear very quickly: a normal smart-contract audit answers only part of the question. A contract audit checks whether deployed code behaves as intended and whether an attacker can make it behave differently. That is necessary, but for autonomous agents it is not enough.
Some of the worst failures do not require a smart-contract bug at all. The contracts can execute exactly as designed, and the allocation can stay inside every limit the code enforces. The behaviour was permitted. The capital is still gone, because a limit was set too high, a data source was wrong, a protocol was incorrectly classified as safe, or the agent never checked whether enough withdrawal liquidity existed.
These failures can come from several other parts of the system:
- Off-chain decision logic. The optimiser or strategy engine deciding where capital should go. This is often one of the largest and least-reviewed parts of the system.
- Permission scope. What the agent is actually allowed to do, and whether those boundaries are technically enforced or only documented.
- Data. The inputs used to make decisions, and what happens if they are stale, manipulated, unavailable or dependent on a single source.
- Custody topology. Whether users are isolated from one another or share a common pool where one failure can affect everyone.
- Change control. Who can modify contracts, strategies, infrastructure or permissions after deployment, and how quickly they can do it.
The assessment target therefore cannot be only the smart contracts. It has to be the full system.
Three questions, three pillars
Rather than starting with a long list of security topics, the framework starts from three questions an allocator should be able to answer before committing capital.
Security asks whether the agent can be compromised or made to behave in an unintended way. Its five sub-criteria cover whether the agent follows a standardised framework for behaviour and permissions, the volume and credibility of its audits, their depth, their scope, and the upgradeability of its contracts and software.
Risk asks whether the agent makes safe allocation decisions while operating normally. Its five sub-criteria cover pre-deposit risk checks, collateral and exposure checks, risk event detection, exit mechanisms and emergency controls, and agent constraints and execution limits. Put simply: Security asks whether the code is sound, and Risk asks whether the agent makes good decisions with sound code.
Robustness asks whether the underlying system is reliable. Its three sub-criteria cover the use of on-chain and off-chain data, the number of data sources and oracles, and the level of funds segregation.
These questions should remain separate because an agent can be strong in one area and weak in another. An agent can have excellent smart-contract security and still make bad allocation decisions, or manage risk well while depending on a single fragile data source. Combining these areas would hide differences an allocator needs to see.
Security and Risk carry more sub-criteria than Robustness, five each against three, which reflects how much of an agent's trustworthiness depends on how it is built and how it behaves while running. The scoring itself is straightforward: agents are scored from 0 to 10 on each pillar, a score of 6 is the minimum threshold for scoring eligibility, and the overall score is the sum of the three pillar scores.
Four problems we had to solve
Defining the pillars was relatively straightforward. The harder part was deciding how individual controls should actually be scored, and four questions in particular shaped the framework.
1. Where do the limits live?
This became one of the most important questions in the framework, and it is one of the first questions we would ask any agent team. Most agents have risk limits: maximum exposure per protocol, leverage ceilings, slippage limits, approved markets or other restrictions. The values may be completely reasonable and clearly implemented in the system.
But the more important question is:
If the off-chain agent were fully compromised, which of those limits would still hold?
If an exposure cap exists only in a configuration file used by the optimiser, a compromised optimiser can ignore it. The same applies to limits enforced only in the backend, SDK or operational procedures. These mechanisms are still useful, but they do not provide the same security property as a restriction enforced independently from the compromised component.
For this reason, the execution-limits criterion only counts limits enforced on-chain, where a transaction that exceeds the allowed boundary reverts. Nothing else scores there. An exposure cap that is merely watched off-chain still earns points elsewhere in the framework, under exposure monitoring, because monitoring is genuinely valuable. But it is a different property, and the framework does not treat it as prevention.
The distinction is between two different things:
- Detection: noticing that something unsafe has happened;
- Prevention: making the unsafe action impossible in the first place.
The same logic runs through the permission framework criterion. Permissions that exist only in documentation, or at the prompt and off-chain layer, fail the threshold outright, because they cannot be relied on under adversarial conditions. Passing agents enforce core actions on-chain through approved targets, allowlists, spending caps, time bounds and revert-on-violation.
For many teams, improving this area does not require redesigning the whole system. The limits are often already well defined; they simply need to be enforced at a stronger layer.
2. Grade properties, not brands
An early version of the rubric included a list of well-known audit firms, and higher scores were linked to being audited by one of those firms. CODESPECT was included on that list, and we recommended removing the list, including our own name.
There were two main reasons. First, a framework should evaluate security properties, not logos. If higher scores depend on hiring a particular company, the framework becomes a procurement checklist. A shallow engagement with a famous firm could then score better than a thorough engagement with a less-known but capable auditor, which does not give the allocator better information.
Second, a list of approved firms ages badly. The security industry changes quickly: new firms appear, existing firms change, teams move between companies, and reputation alone does not guarantee the quality of a specific engagement.
The published framework now grades on the number of distinct independent auditors rather than firm prestige, and states plainly that no auditor is treated as inherently top-tier. The thresholds are concrete. A single credible audit passes, and only the genuine absence of verifiable review fails. The tiers escalate with cross-firm validation, from two auditors to three or more, and the top tier is reserved for security treated as an ongoing process rather than a one-time purchase: recurring re-audits across releases, and a meaningful, active bug bounty.
Repeat engagements with the same auditor still provide value because that auditor understands the system and can follow its evolution, but they do not substitute for an additional independent auditor. The same principle applies across the framework. In risk event detection it is stated directly as capability over procurement: a third-party risk-intelligence provider and an equivalent purpose-built detection layer count equally, because what is scored is detection coverage and reaction speed, not whether a vendor is present. Named standards, oracles and vendors are examples of evidence, not requirements.
3. Never average away a weak point
Some criteria contain several separate dimensions, and the obvious approach would be to calculate an average. The framework does the opposite: when several security-critical dimensions are combined, the score is set by the weakest one.
Audit scope is the clearest example. It grades audits on three dimensions:
- scope breadth;
- methodological rigor;
- remediation completeness.
The tier is set to the lowest of the three, so an exhaustive scope cannot lift the score while High-severity findings remain open. Remediation works as a strict ladder, running from "no Critical or High open" at the passing tier to "all severities resolved and validated by re-audit" at the top.
Upgradeability follows the same principle. The framework identifies every surface that carries mutable, risk-bearing logic and scores the weakest one:
- upgradeable contracts;
- the off-chain deployment pipeline;
- key and session-key infrastructure.
A lone upgrade key or a single CI/CD deploy authority does not clear the floor, and multi-party control is required to pass. A well-governed proxy does not provide much protection if one engineer can still deploy arbitrary production code through another path. An attacker will target the weakest path, which is why averaging can be misleading in a security framework. If one path can compromise the system, that path matters.
Notably, the framework does not penalise an agent for holding mutable logic off-chain rather than behind a proxy. What it does not accept is the absence of any documented change-control governance, on-chain or off.
4. Stop the same mechanism getting paid three times
Some architectural decisions improve several security properties at once, and per-user smart accounts are a good example. They improve emergency recovery because the user may be able to withdraw funds or revoke the agent independently. They improve funds segregation because users do not necessarily share one central pool, and they can improve the permission model because the agent operates through scoped and revocable permissions.
All of those benefits are real, but if the same mechanism receives full credit in three different scoring categories, the framework starts double- or triple-counting the same architectural decision. The solution was to define clear boundaries between criteria:
- the ability to revoke permissions or halt the agent is evaluated under exit mechanisms and emergency controls;
- isolation between users is evaluated under level of funds segregation;
- the scope of actions the agent can perform is evaluated under the standardised permission framework;
- quantitative limits such as maximum exposure or leverage are evaluated under agent constraints and execution limits.
The boundaries are written into the criteria themselves. The execution-limits criterion says explicitly that an exposure cap merely watched off-chain is credited under exposure monitoring, not there. The same underlying architecture can support several properties, but each scoring row should evaluate a different property. Otherwise, the final score may look more diversified than the underlying security actually is.
What this looks like from your side of the table
If you are building an agent that may eventually be assessed under this framework, several recurring patterns are likely to affect your score. These are general patterns we have seen across assessments rather than references to any specific project.
Your caps may be enforced at the wrong layer. This is one of the most common gaps. The exposure limits are often sensible and well designed, but they exist entirely inside the off-chain agent. If compromising the agent also gives an attacker control over the limits, those limits are not an independent security boundary. Moving the most important restrictions on-chain can significantly improve the system without requiring a complete redesign.
Identify your critical inputs and avoid depending on only one source. The framework treats "number of sources" as shorthand for having no single point of failure per critical input, not as a raw count of vendors and not as a checklist of named oracles. It first identifies the agent's actual critical decision inputs, then scores each one for redundancy: single-sourced, or two or more independent sources with cross-validation, deviation limits or graceful fallback. Inputs that materially change allocation decisions include:
- protocol APR;
- utilisation;
- available liquidity;
- exchange rates;
- collateral values;
- protocol health metrics.
One pattern is called out as a tier-capping flaw: a single-source failure that silently biases decisions, such as coercing a failed feed to a default value. The system then continues operating normally even though the number it is using no longer represents reality.
Test the exit path without your own front end. Per-user non-custodial accounts, where the user owns the smart account and the agent holds only scoped, revocable permissions, earn a high recoverability floor. They do not automatically earn the top tier. The questions that decide the upper tiers are:
- Is the independent-access path documented?
- Has it been tested?
- Can users exit if the project's front end and backend are unavailable?
- Is underlying-protocol liquidity stress handled?
Passing requires a working halt and basic withdrawal. The top tiers require worst-case recoverability that is explicitly bounded, tested, and still functional under infrastructure degradation and liquidity collapse. Custody architecture alone cannot solve protocol liquidity: if the underlying lending market is at 100% utilisation, having full control of your wallet does not create withdrawal liquidity.
Evidence has to be verifiable, or it does not count. The framework is evidence-based, and where evidence for a higher tier is absent, the category is scored conservatively rather than assumed in the agent's favour. This is stated in the individual criteria rather than left implied. Audit volume counts only audits that are independent, published and independently verifiable. Audit depth explicitly excludes internal-only or stale reviews. Upgradeability treats the absence of any documented change-control governance as a failure. If a control exists but cannot be demonstrated to an outside reviewer, it will not lift your score, so publishing the evidence is part of the work rather than an afterthought.
Funds segregation is a ladder, and per-user isolation sits at the top of it. An architecture where user funds are mixed into a single shared contract with no reliable way to verify individual ownership fails this criterion. Passing requires at least logical separation, meaning funds may sit in a shared contract provided strict, mathematically verifiable internal accounting governs them. Tiers then escalate from logical segregation to partial physical segregation.
The top tier is reserved for architectures that maintain strict per-user on-chain isolation with strong unit economics, eliminating reliance on pooled funds entirely, so that execution, safety and operational autonomy remain intact even at very small individual balances, provided the isolation does not create prohibitive gas overhead. That last condition matters. Per-user isolation is not scored as an architectural checkbox; it has to be economically workable at realistic balance levels. If your design solves the unit economics of isolated accounts, document it, because it is part of the security model.
What we still have not settled
No trust framework should pretend that every design question has been solved permanently. There are still several areas where the scoring model may evolve.
Auditor independence needs a sharper definition. Using multiple independent auditors provides different perspectives, but a firm that has reviewed the same system repeatedly over several years sits somewhere between a completely fresh reviewer and an internal security team. That long-term context is valuable, but the auditor may also be less likely to approach the system with completely fresh assumptions. The current framework treats repeat engagements as valuable continuity, but not as a substitute for another independent reviewer. Whether that balance is exactly right remains an open question.
The number of audits may not be the best proxy for assurance. Removing the prestige-based audit-firm list was important, but counting independent auditors introduces another problem: three shallow reviews are not necessarily stronger than one very deep review. Finding an objective way to measure audit depth is difficult, and the framework needs to capture quality without reintroducing subjective brand rankings.
On-chain enforcement introduces an architectural bias. The framework strongly rewards controls that continue to work even if the off-chain agent is compromised. In practice, that means architectures with on-chain enforcement often score better than architectures that depend heavily on trusted off-chain infrastructure. We think that preference is usually justified, because a control that survives the compromise of another system component is generally stronger than one that disappears with it.
Still, this is a design preference built into the framework rather than a completely architecture-neutral measurement. Some teams may achieve similar guarantees through different designs, and the framework should remain open to evidence that demonstrates equivalent security properties.
There is also a structural conflict to consider. Owney created and publishes the framework while also operating an aggregator that integrates the agents being assessed, which creates a potential conflict of interest. The framework addresses this by relying on independently verifiable evidence rather than self-attestation. The methodology was developed together with three external security firms, CODESPECT, Core3 and Hacken, and those firms scored the agents independently of Owney. Agent development teams can review assessments for factual accuracy but do not set their own scores.
Even with those controls, users and allocators should still consider who produces an assessment when interpreting the result. A trust framework should make that evaluation easier, not ask users to ignore it.
Where this goes
A trust score is a point-in-time assessment of a deployment. It is not a warranty or a recommendation. Agents change, audits age, infrastructure evolves, and scores are updated as new evidence appears, such as new audits, protocol upgrades, governance changes and security incidents.
It is also worth being clear about what the score does not cover. The framework assesses the agent layer: the autonomous allocator together with its smart-account, permission and data architecture, and the audits and controls around it. It does not independently re-audit the underlying protocols an agent routes into, such as Aave, Morpho or Compound, nor the individual pools. Protocol risk is captured indirectly through the Risk pillar's pre-deposit and exposure checks, but an agent score is not a protocol audit.
The main value of the framework is the shared vocabulary behind the score. Before it existed, an agent team could say "we're audited and non-custodial" without answering the questions an allocator actually needs to understand:
- Which parts were audited?
- Were the findings fixed?
- Who controls upgrades?
- Can the agent exceed its documented limits?
- What happens if the backend is compromised?
- Can users exit independently?
- What data does the strategy rely on?
- Are users isolated from each other?
The Agent Trust Framework gives teams, allocators and security reviewers a common structure for answering those questions, and the assessments it produces are published openly at risk.owney.app.
If you are building in this space and want to understand how your architecture would score against the framework, we would like to hear from you.
CODESPECT. Code. Inspect. Protect.