8 reasons the AI governance toolstack is being built onchain

In March 2026, CTO Magazine published an article titled “AI Transformation is a Problem of Governance.” The article was well received, widely searched, and even inspired copycat pieces trying to build on its success.

In it, the authors argue that the hardest part of enterprise AI transformation is no longer access to the technology. AI is now everywhere. The bigger problem today that small businesses and big institutions face is governance.

Organizations need the ability to intervene before an autonomous system takes a high-risk action. They need better ways to define what AI systems are allowed to do. 

Many have pointed out that blockchains were building financial rails for AI before AI fully entered the spotlight. Not intentionally, but as a result of the problems they were already solving in decentralized finance.

In a similar way, blockchain and web3 infrastructure have also been building many of the tools needed for AI governance.

Because of these advancements and new ones created specifically for AI money movement onchain, developers can now use blockchain and Web3 infrastructure to make AI governance more programmable, verifiable, and enforceable than ever before. 

As agents begin participating in workflows with real consequences, governance has to move closer to the point of execution. It needs to protect asset transfers from unintended agent actions, unclear prompts, and behavior outside the system’s intended scope.

Onchain and web3 infrastructure make that possible.

Why the governance gap is an infrastructure gap

AI governance is often discussed as a boardroom, compliance, or policy problem. It is all of those. But for autonomous systems, it’s also an infrastructure problem.

A company can write a rule that says an agent should not move more than $10,000 without approval. But unless that rule is enforced, the control depends on the application or the agent’s own instruction path.

This is where onchain infrastructure becomes a governance layer.

Together with new ERC standards that are beginning to define identity, trust, and commerce primitives, wallet infrastructure providers like Turnkey offer wallets scoped with policies that  determine what agents are allowed to sign.

The agent can propose an action. The infrastructure decides whether that action is authorized.

The CTO article shows how broad AI governance has become. Through an infrastructure lens, eight problems stand out, each centered on enforcing rules when AI systems take action.

1. Data governance and provenance

Data governance and provenance are about making sure agents act on trusted information. AI agents are only as safe as the data they are allowed to use.

Turnkey’s verifiable architecture is designed so enclave applications do not blindly trust data that can be changed outside the enclave. 

This gives developers a stronger foundation for agent workflows. Vendor addresses, wallet permissions, signer roles, organization settings, and policy rules can all be checked before an agent’s action is evaluated for signing.

An agent does not get broad authority just because it has access to a workflow. It can act only on the data and operations the infrastructure is designed to trust.

In multi-agent systems, where several agents may coordinate around shared assets and workflow state, chains such as Sui can make that shared state more explicit, while policy (ala Turnkey’s policy engine) still determines which agent can authorize the next action.

2. Ethical alignment and fairness

Bias testing, fairness evaluation, model behavior reviews, and ethical risk assessments happen upstream. At this point in time, onchain tools and infrastructure will not test whether a model is fair or not.  

But they can make those audits more concrete.

For example, If a marketplace uses AI agents to assign jobs, route payments, or select counterparties, the fairness question sits upstream: why did the system make those decisions? But the surrounding infrastructure can preserve the record that auditors need to inspect. 

Which agent initiated the action. Which wallet or identity it used. What job, payment, or contract interaction it requested. What policy evaluated the request. What transaction was ultimately signed.

That does not solve fairness by itself. But It gives fairness and governance teams a clearer evidence trail to review.

3. Transparency and explainability

AI governance requires transparency. In financial workflows, a user should not have to trust that an agent signed the right transaction. They should be able to verify what the agent asked to do, what controls evaluated the request, and what was ultimately executed.

This is where transaction parsing and smart contract evaluation become important.

Instead of signing an opaque payload, wallet infrastructure can parse transaction metadata before signing. On EVM, that can include the transaction source, destination, amount, chain ID, and other relevant details. This gives the application and its policies a clearer view of the action an agent is proposing.

Smart contract interfaces add another layer of specificity. Developers can upload ABIs and IDLs so policies can evaluate individual function calls and their arguments, rather than treating every interaction with a contract as the same type of action.

That distinction matters for agents. For example, a DeFi agent may be instructed to deposit USDC into an approved vault, but the transaction it prepares could call a different contract method, approve a new spender, or direct assets to an unexpected address. 

By providing this level of transparency and activity logging, teams on Turnkey can see what action was requested, what transaction was constructed, what policy evaluated it, and whether the signing layer allowed or blocked it. That gives developers, users, and compliance teams a clearer record of how an agent’s decision became an onchain action.

4. Risk management and classification

Enterprise AI governance depends on classifying risk and applying the right control to each action.

For agents, that classification should map directly to signing permissions.

Turnkey’s policy engine lets teams define who can act and under what conditions. Policies are written in JSON and evaluate consensus and condition rules. Almost all actions are denied by default, and explicit deny rules take precedence.

That gives developers a practical way to encode risk tiers.

A treasury agent might be allowed to move small amounts of USDC between approved internal wallets. It might be allowed to pay known vendors under a fixed threshold. But it should not be able to add a new recipient, approve a new spender, withdraw from treasury, or modify wallet permissions without additional approval.

ERC-8183 can make those risk boundaries more explicit for agent-to-agent commerce. Rather than treating every machine-initiated payment as a simple transfer, the standard structures work around jobs, escrow, deliverables, evaluation, and settlement. That gives policy a clearer workflow to govern.

The agent can request the action. Turnkey decides whether the request is allowed.

5. Technical robustness and security

Security is the strongest fit for Turnkey’s architecture.

If an agent can move money or interact with contracts, the most important question is simple: can the agent access the raw private key? With Turnkey, the answer is no.

Turnkey runs critical security operations inside secure enclaves: hardware-isolated environments that keep sensitive code and data separated from the rest of the infrastructure. Key generation, transaction signing, and policy evaluation all happen within this protected boundary, and private keys never leave it.

As a result, a trading, payments, treasury, or DeFi agent does not need direct access to key material. It can request an action, but Turnkey evaluates the request against the relevant policy before anything is signed. The enclave produces a signature only when the action is allowed.

This protects against the failure modes agentic systems make more likely. A prompt-injected agent may ask to send funds to the wrong address. A compromised application server may submit a transaction the user did not intend. 

In each case, the question is not only whether the agent behaved correctly. The question is whether the signing layer allowed the action.

The agent can be wrong. The wallet still cannot be misused outside policy.

6. Human oversight

Human oversight should not depend on someone catching a bad action after it happens. It should be part of the signing path.

Turnkey policies can require human approval before sensitive actions are signed. That maps directly to the human-in-the-loop model, but with stronger enforcement.

For example, when an AI agent prepares a large treasury transfer, the transaction can be held until one or more authorized finance users approve it. This is not a dashboard reminder. It is a signing condition.

Human oversight also connects to delegated access. A user can grant an agent limited authority to act on their behalf without giving that agent root control over the wallet. An agent can be allowed to place a specific limit order, execute a defined trading strategy, or pay a recurring invoice while remaining unable to transfer the full wallet balance.

Structured agent-commerce flows can also create clearer points for intervention. In an ERC-8183-style workflow, a human reviewer or designated evaluator can be required before escrow is released or a disputed job is settled. The workflow defines the stages of the transaction. Policy determines which stage requires approval and who is allowed to provide it.

That is the model enterprises need: scoped autonomy, not unrestricted delegation.

7. Continuous monitoring, auditability, and lifecycle management

Turnkey provides the audit foundation for monitoring.

Every request, policy evaluation, state change, and signed action can become part of an audit trail. Onchain transactions add a public execution record. Together, they give teams a clearer view of how autonomous systems are behaving.

Agent identity makes that record more useful. ERC-8004 and Sign In With Agent give agents a way to authenticate cryptographically with keys tied to an onchain identity, rather than appearing as anonymous API keys or interchangeable service accounts. A treasury agent, trading agent, support agent, and settlement agent can each have a defined role, permission scope, and activity trail.

That makes it easier to answer the core audit questions: who acted, what were they allowed to do, and what was signed? Turnkey policies define the allowed action space. Transaction parsing shows what a transaction is trying to do. The signing flow records that the request passed policy evaluation before a signature was produced.

For a complete monitoring stack, a production AI governance program still needs dashboards, alerts, drift detection, model evaluation, incident response, and operational analytics.

Teams can then monitor behavior by role and authority boundary. They can see whether a trading agent is repeatedly requesting denied swaps, whether a settlement agent is attempting actions outside approved job flows, or whether a support agent is approaching its refund threshold. If an agent’s role or workflow changes, its authority can be updated, suspended, rotated, or retired without giving it open-ended control.

Turnkey is the source of high-integrity signing, policy, and identity data that those dashboards can use.

8. Legal and regulatory compliance

Legal and regulatory compliance depends on controls and evidence.

A company needs to show not only that it had rules, but that those rules were enforced. This is especially important when AI agents interact with money, users, regulated assets, or financial workflows.

Turnkey policies can encode compliance rules directly into the signing path. A stablecoin payments agent can be restricted to approved networks, assets, recipients, and transaction thresholds. A treasury agent can be blocked from interacting with unapproved DeFi protocols. A customer-facing agent can be prevented from sending funds to a new address unless that address has passed the company’s approval process.

Transaction parsing makes these controls more precise. The same wallet can perform very different actions. Sending a small USDC payment to an approved vendor is not the same risk as granting unlimited token approval to a new contract. Calling a deposit function on an allowlisted vault is not the same as calling an admin method on that contract.

Turnkey lets teams treat those actions differently before signing.

Verifiable data also supports compliance evidence. If organization state, policy state, and signer permissions are cryptographically verified, teams get a stronger record of what data the signing decision relied on.

The compliance program still lives with the business. Turnkey provides infrastructure that can enforce the rules and preserve the evidence.

How applications govern agents with Turnkey

All governance needs point to the same infrastructure question: where should control be enforced?

For AI agents working with digital assets, governance has to sit close to execution. Agents can reason, plan, and request actions, but the critical moment comes when they try to move funds, change permissions, or interact with a contract. That is the layer Turnkey is built to secure. 

Enforcing policy within secure enclaves

Turnkey runs key generation, policy evaluation, and transaction signing inside AWS Nitro enclaves. These are hardware-isolated environments that keep sensitive operations separate from the rest of the application stack.

Policies are evaluated inside the same boundary. The agent submits a request. Turnkey checks whether that request is allowed. Only then can a signature be produced.

That matters for autonomous systems. If an agent is manipulated by a bad prompt, a compromised workflow, or faulty logic, it still cannot move assets outside the rules you define.

The agent can be wrong. The wallet cannot sign outside policy.

Deny by default, permit by exception

Turnkey’s policy engine starts from no access. Actions are denied unless a policy explicitly allows them, and explicit deny rules take priority over permissions.

This gives teams a safer foundation for agent governance. Instead of giving an agent broad wallet access and trying to restrict it later, developers can define exactly what the agent is allowed to do from the start.

Control specific actions, not just wallets

Traditional wallet access is often binary. An agent either has access to a wallet or it does not.

Turnkey makes control more precise. Policies can evaluate transaction details, contract interactions, recipients, chains, methods, and parameters before signing.

For example, an agent can be allowed to call a deposit function on an approved contract, while being blocked from calling an admin function on that same contract. It can be allowed to pay an approved vendor, while being blocked from sending funds to a new address. 

Verify the state behind every signing decision

Governance depends on the integrity of the data behind each decision. Policies, permissions, and organization state need to be trustworthy before a signature is produced.

That gives teams a clearer record of what the signing decision relied on, not just what happened after the transaction was signed.

Built for how agents actually operate

Turnkey does not replace the model, the agent framework, or the compliance dashboard. It gives developers a programmable enforcement layer for the actions that matter most. Agents can propose actions. Turnkey controls whether those actions are authorized.

For developers building smart applications on onchain infrastructure, this is what agent governance requires: not just software that tries to make agents behave, but infrastructure that enforces what agents are allowed to do.

Turnkey: Wallet infrastructure for smart AI governance 

Turnkey gives developers the infrastructure they need to govern agents: secure enclaves for key protection, policy-controlled signing for scoped authority, transaction parsing for action-level enforcement, verifiable data, and audit trails for accountability.

Chain-level infrastructure like Agent identity, structured commerce, and shared workflow state reinforce those controls at the points where agents coordinate and transact. And chains like Sui show how multi-agent systems can coordinate around a shared state without giving every agent the same authority.

Together, these pieces form a concrete governance toolstack for autonomous agents.

• Define who is acting with identity.
• Define what they can do with policy.
• Protect signing authority with secure enclaves.
• Verify the action with transaction parsing.
• Record the result through onchain execution

AI governance can’t stop at what agents say. It has to control what agents can do, especially when they can move assets, trigger transactions, and create real financial risk.

Get started with Turnkey today.‍