admin
An AI agent may execute financial instructions for weeks, but the most consequential risk might not be the model’s next output. It may be an upgradeable smart contract whose owner can replace the code controlling custody or delegated spending. A proxy makes software maintenance convenient, while introducing governance assumptions that users rarely see in a product demo. ERC-1967 standardizes important storage slots; it does not guarantee that the people holding upgrade authority will behave safely. This article proposes an audit-ready review of ownership, code changes, notice periods and withdrawal routes.
Identify every authority that can change behavior
Start with the proxy address, implementation address and administrator or beacon authority. ERC-1967 defines widely used storage slots for implementation, beacon and admin information so tools can inspect a proxy consistently. Those slots reveal where control may reside, but not necessarily who exercises operational authority through a multisignature, role manager or higher-level governance contract. A credible security review follows the authority chain until each controlling signer and contract is understood.
Draw a simple control graph showing which entity can upgrade logic, pause transfers, edit spending limits, change oracle providers and authorize an emergency recovery. The effective control surface can be larger than the nominal proxy administrator. Inspect events such as Upgraded and AdminChanged, as suggested by ERC-1967, and compare them with the state visible in the deployment registry.
Treat upgradeability as a product promise
Users may believe they authorized a limited agent to trade a specific asset once each day. If an upgrade can silently widen permissions or redirect treasury flows, the product’s real promise differs from the onboarding text. Terms should distinguish the user’s transaction authorization, the application’s upgrade authority and the right to revoke service. They are separate decisions, even when the UI presents one convenient button.
Create a one-page upgrade disclosure with the admin model, expected maintenance scope, emergency controls and withdrawal procedure. Avoid absolute claims such as ‘immutable’ or ‘non-custodial’ unless every relevant dependency supports them. The choice to have upgradeable code is not inherently unsafe; undisclosed or practically unlimited upgrade power is what creates a serious trust gap.
Specify a meaningful timelock and emergency lane
A timelock gives affected users time to inspect and respond to a proposed implementation change. Define a proposal event, implementation-code hash, independent review, minimum notice period and executable time. A seven-day delay might be adequate for one product and inappropriate for another; this is a governance design assumption, not a universal recommendation. Emergency upgrades for active exploits need a narrower lane with special signers and a post-incident review.
The essential design question is what happens if a malicious administrator tries to shorten the notice period. The code should not allow the same unrestricted party to bypass the delay for ordinary upgrades. Publish all proposed changes in an accessible human-readable format and retain the historical implementation addresses. Alerts that only technical experts can parse do not provide meaningful user protection.
Run state-preserving upgrade simulations
A proxy upgrade retains storage while changing logic. That is precisely why storage layout errors and initializer mistakes can be dangerous: user balances, roles or spending policies may be read differently after deployment. Build a rehearsal against a realistic fork or controlled test environment with representative accounts and balances. Assert invariants before and after the upgrade, including total asset accounting, role boundaries, withdrawal ability and allowance ceilings.
Keep the simulation result, contract bytecode hashes, review signatures and migration notes together. Test the rollback process and deliberately fail one invariant to confirm that the release gate blocks a bad change. An audit report for old code is not a blanket endorsement of all future implementations. Each material upgrade must earn its own evidence of compatibility and security.
Give users a working exit window
A published exit policy is only credible if users can actually withdraw or reduce delegation before new logic takes effect. Test a user with pending tasks, unsettled assets, multi-chain balances and insufficient native gas. State whether disabling the AI agent revokes on-chain approvals or only stops the application from initiating future requests. Often these controls are distinct, and UI language should reflect that distinction.
Keep the shutdown interface available even if the AI inference service is unavailable. A human-readable withdrawal transaction and independent wallet route can make exit rights more resilient than a single application screen. Monitor the proportion of accounts that could exit during a rehearsal; report failures and the time required to repair them. The user’s ability to withdraw should not rely on continued trust in the agent’s responses.
Evaluate the full trust stack, not a single proxy slot
A useful review checklist contains the proxy and implementation addresses, signer custody model, timelock behavior, dependency upgrades, oracle permissions, pause controls and rollback plan. Score each on evidence, not marketing claims. For example, an unaudited admin rotation with no public event record is materially different from a multisignature change with delay and independent verification, even if both systems use the same proxy template.
Compare the custody and delegation assumptions in EIP-7702, which allows EOAs to delegate execution through code, with the separate ERC-1967 proxy pattern. They solve different technical problems, but both illustrate why users need clarity about changing execution authority. Long-lived autonomous finance requires a right to inspect, a right to limit and, above all, a practical right to leave.
