Look for sensitive functions that gate on tx.origin, isContract, extcodesize, or code.length, especially where the result controls withdrawals, liquidations, minting, or signature validation. Warning signs include execution paths that were only tested against static address types, registrations that assume an address will remain an EOA, and low level calls that treat success as guaranteed. Those patterns can break once delegation is introduced.
Delegation Changes the Assumptions Your Code Was Written Against
EIP-7702 changes what an externally owned account can do during execution, so code that relied on “this address can never behave like a contract” becomes fragile. The most common failure point is not the delegation feature itself, but logic that uses address type as a shortcut for trust, permissioning, or identity checks. When that shortcut appears in withdrawal flows, liquidation logic, minting gates, or signature validation, the code may still compile cleanly while the business rule silently stops matching reality.
That is why the most useful warning signs are places where the codebase equates “EOA-like” with safe, immutable, or non-executable. If a system was built around static address assumptions, delegation can invalidate those assumptions without any obvious interface change. In practice, many security teams only discover this after a live code path starts behaving differently under delegated execution rather than during the original unit test coverage.
How to Spot Fragile Patterns Before They Break
The highest-risk pattern is any branch that treats tx.origin, isContract, extcodesize, or code.length as a reliable proxy for user type or execution safety. Those checks often look tidy in reviews, but they become brittle when the code uses them to decide whether an address may withdraw funds, receive a mint, bypass a registration step, or prove a signature. A delegated account can invalidate the assumption that the address is effectively static, even when the address itself has not changed.
Another warning sign is a codebase that has never been exercised against delegation-aware scenarios. If tests only cover simple wallet interactions, they may miss places where internal accounting, access control, or signature verification depends on an account remaining externally inert. Low level calls deserve particular attention when the code treats a successful call as proof that the target behaved as expected, because success does not guarantee the surrounding assumptions still hold.
- Review any branch that gates privileged actions on tx.origin or contract-detection heuristics.
- Check whether registration, allowlisting, or recovery logic assumes an address will remain an EOA for its lifetime.
- Inspect signature flows for assumptions about who can execute, replay, or delegate a signed action.
- Trace low-level call sites to confirm the code validates outcomes, not just return values.
- Re-run tests with delegated-account scenarios, especially around settlement, minting, and withdrawals.
For broader control design, NIST’s security and privacy control catalogue is useful as a governance reference for access enforcement and system integrity, but it does not replace code-level review of delegation-sensitive logic. A codebase usually breaks first where it confuses account form with account behaviour, and delegation exposes that mistake.
Where the Edge Cases Hide in Real Systems
Tighter account-type checks can reduce accidental access, but they also increase the chance of false confidence when the platform changes how accounts execute. That tradeoff matters most in systems that mix onchain checks with offchain onboarding, risk scoring, or signature-based authorisation, because each layer may assume the others are enforcing a stable identity model.
Edge cases often appear in older code paths that were written for a world where EOAs and contracts were easy to distinguish. A registration module may store an address once and never revisit whether its execution model changes later. A liquidation engine may assume caller behaviour based on code size at one point in time. A signature validator may pass basic tests while still failing under delegated execution because the verification logic is tied to a stale assumption about who can act for the address.
There is no full consensus on every implementation detail that becomes unsafe under delegation, but there is broad agreement that heuristics built around address type are weaker than explicit authorisation logic. The practical break point is where the code treats a historical observation about an address as if it were a permanent property of that address.
NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference when you want to map these failures back to access control and integrity requirements, but the code review still has to prove the assumption chain in the application itself. The guidance breaks down when a project lacks deterministic tests for delegated execution and relies on informal review to catch behaviour that only appears after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1211 — Exploitation for Defense Evasion | Heuristic checks can be bypassed when attacker-controlled execution changes. |
| Recommendation — Hunt for assumptions that let malicious execution bypass contract-detection logic. | ||
| CIS Controls v8 | 6 — Access Control Management | The issue is weak authorization logic tied to address form. |
| Recommendation — Replace address-type heuristics with explicit access control validation. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | Delegation breaks access decisions that rely on static account assumptions. |
| PR.DS-6 — Data-at-Rest Protection | Call success and state assumptions can mask integrity failures in execution paths. | |
| Recommendation — Review access decisions so they do not depend on mutable account behaviour. Validate that critical state changes remain integrity-checked after delegation. | ||
Practitioner Guidance
What to verify: Verify every place where address type is being used as a security decision, not just as an optimisation. If a function becomes unsafe when the caller can delegate execution, treat that as a design issue rather than a narrow bug.
Common mistake: Teams often patch the obvious tx.origin or contract-detection checks but leave adjacent assumptions untouched. The more durable fix is to remove implicit trust in address form and force the code to prove authorisation directly.
What good looks like: The codebase should have tests that cover delegated execution, and critical flows should still behave correctly when the caller is no longer equivalent to a plain static wallet. If a test only passes because the caller was assumed to be “just an EOA,” the control is too weak.
Practitioner takeaway: Treat delegation as an assumption-breaker, not a feature toggle. The real signal of fragility is any business rule that depends on an address remaining behaviourally simple over time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
