Treat them as executing identities, not simple integrations. Teams should define the exact actions the agent may trigger, separate model access from transaction authority, and require audit evidence for each step in the flow. If the agent can route prompts, call tools, and change state, governance must cover the full execution chain, not just the model endpoint.
Why This Matters for Security Teams
AI agents that can execute blockchain transactions are not passive applications. They are executing identities with the ability to propose, sign, route, and sometimes finalize state-changing actions. That shifts governance from model safety alone to transaction authority, policy enforcement, and evidence capture. Current guidance suggests teams should separate prompt access from execution rights, because a harmless-looking model interaction can still lead to irreversible on-chain activity.
The risk is amplified by the autonomy of the agent. Once it can chain tools, read wallets or keys, and act on external signals, static IAM controls no longer describe what it may do at runtime. NHI Management Group’s research on the OWASP NHI Top 10 shows why agentic systems need explicit control over identity, secrets, and execution paths, not just API access. The same principle applies to blockchain flows where one mistaken approval can move assets or alter contracts irreversibly. In practice, many security teams discover the gap only after an agent has already broadcast a transaction, rather than through intentional design.
How It Works in Practice
Governance starts by treating the agent as a workload identity, not a user and not a simple integration. That means binding each agent to a cryptographic identity, then authorizing each transaction at runtime based on task context, risk, destination, amount, and policy. For blockchain use cases, the safest pattern is usually intent-based authorization: the agent can prepare an action, but a policy engine or approval workflow decides whether the action may proceed.
Teams should also use just-in-time credentialing for any signing or wallet access. Short-lived tokens, scoped transaction keys, and per-task secrets reduce the damage window compared with static wallets or long-lived API keys. This aligns with the broader control logic described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where lifecycle control matters as much as initial issuance. The policy layer should also preserve audit evidence: the original prompt, tool calls, policy decision, transaction draft, final hash, and revocation event.
- Use workload identity for the agent, such as OIDC-backed or SPIFFE-aligned identities, so the system can prove what the agent is.
- Separate model access from transaction authority so prompt injection does not equal signing power.
- Apply real-time policy evaluation for each on-chain action, rather than pre-approving broad wallet permissions.
- Require ephemeral signing privileges and revoke them when the task completes or times out.
- Log the full execution chain so reviewers can reconstruct how the transaction was reached.
For threat modelling, pair this with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, because they force attention on governance, traceability, and harmful autonomy rather than only model output quality. These controls tend to break down in high-frequency trading, DeFi automation, or multi-chain arbitrage environments because latency pressure pushes teams to widen permissions and skip human review.
Common Variations and Edge Cases
Tighter transaction controls often increase operational friction, so organisations have to balance speed against blast-radius reduction. That tradeoff becomes sharper when agents handle low-value transfers, protocol interactions, or large numbers of microtransactions.
There is no universal standard for this yet, but best practice is evolving toward tiered authority. Low-risk actions may be auto-approved within strict limits, while higher-risk actions require step-up approval, secondary signatures, or transaction simulation before broadcast. Teams should also distinguish between read-only market intelligence agents and write-capable agents, because the governance burden changes materially once an agent can mutate state.
Edge cases matter. Smart contract calls may appear benign but still trigger downstream actions, and bridge or cross-chain workflows can multiply risk because one agent decision may fan out across multiple ledgers. If the agent can route prompts into wallet helpers, MPC services, or signing daemons, governance must cover every hop in that path. The practical lesson is to govern the execution chain, not just the wallet, because blockchain reversibility is limited and mistakes often become permanent before any human sees the event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent autonomy and tool chaining create the core transaction risk. |
| CSA MAESTRO | GOV-2 | MAESTRO addresses governance for autonomous agent decisions and actions. |
| NIST AI RMF | AI RMF governance is needed for accountability, traceability, and risk treatment. |
Define agent decision boundaries, approval gates, and traceable execution paths before enabling transactions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
