Agentic AI in the Enterprise: Delegation You Can Audit

An assistant that drafts an email asks for trust once: a person reads the draft. An agent that books freight, pays a supplier or calls a production API asks for trust on every action, often with nobody watching. That shift is why Gartner lists inadequate risk controls, alongside cost and unclear value, among the reasons it expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027.

This article treats agent governance as an engineering problem: who delegated what, to which agent, within which limits, and what record proves it afterwards.

The frameworks agree on the shape

Several recent frameworks converge on the same structure.

• Singapore's Model AI Governance Framework for Agentic AI, launched by IMDA in January 2026, organises the work into four dimensions: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls, and enable end-user responsibility. It treats agent identity as a core way to bound risk.
• The OWASP Top 10 for Agentic Applications for 2026 catalogues the failure modes security teams should plan for, including goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures and rogue agents.
• The EU AI Act requires high-risk systems to record events automatically over their lifetime (Article 12) and to be designed for effective human oversight, including the ability to override or stop them (Article 14); deployers must keep the automatically generated logs for at least six months (Article 26).

The takeaway: bound the agent before it runs, record what it did while it runs, and keep a human able to stop it.

A delegation model in four layers

1. A root that answers for the agent. Every agent should trace to a person or legal entity who is accountable for it. An agent that answers only to itself cannot be held to anything.

2. Terms, not just permissions. Role-based access says what an agent may touch. Agents also need terms: spend per transaction, per hour and per day; allowed counterparties; allowed operations; and an expiry. Terms should be checked by the system that executes the action, not by the agent's own code.

3. Budgets as hard limits. The safest spending limit is a funded balance the agent cannot exceed, rather than a policy it is asked to respect. Payment protocols are moving the same way: AP2 represents a user's instructions as a signed Intent Mandate and an approved purchase as a signed Cart Mandate, so the authority behind a payment is explicit.

4. Revocation that works in seconds. Pausing an agent, withdrawing its funds and revoking its credentials should be one action, and should cascade to every agent it spawned.

Proving who is calling

When an agent calls a service outside your own perimeter, the service needs to know which agent is calling, who stands behind it and under which mandate. HTTP Message Signatures (RFC 9421) give a standard way to sign a request's method, path, headers and body digest, so a receiving server can verify per request rather than per session. Keys that sign for agents should live in hardware, not in environment files.

A control checklist

Before an agent goes to production, check:

• Identity. Unique per agent; traceable to an accountable root; key held in hardware.
• Scope. Terms written down and enforced outside the agent: spend caps, counterparties, operations, expiry.
• Tools. Each tool's arguments validated against a schema; destructive tools behind an approval step.
• Inputs. Content the agent reads (documents, web pages, emails) treated as untrusted, since goal hijacking enters that way.
• Oversight. A stop procedure that a named person can trigger, tested before launch.
• Records. Every action logged with the authority it ran under, the model that produced it and the cost, in a form a third party can verify without trusting the operator.
• Retention. Logs kept at least as long as the applicable rule requires (six months for deployers of high-risk systems in the EU).
• Differentiation. Not every agent needs the same controls; a read-only research agent and a payments agent should sit in different risk tiers.

Regional notes

The EU sets binding logging and oversight duties for high-risk systems. Singapore offers voluntary but detailed guidance specific to agents. The US and UK rely more on sector regulators and existing law on payments, consumer protection and data. Firms operating across regions should design to the strictest record-keeping duty they face and apply it everywhere; maintaining several logging regimes costs more than one good one.

What this means for agent builders and security teams

• Put limits in the execution layer, where the agent cannot argue with them.
• Give every agent its own identity and keys; shared service accounts make attribution impossible.
• Make evidence a product feature: an auditor, a merchant or a regulator should be able to check a record without access to your systems.

Where Tenzro fits

Tenzro gives humans, institutions and agents one identity model with delegation built in. What is built today:

• Accountable roots. A machine identity is admitted only if a human or institution delegated it, or if an attestable hardware root of trust stands in their place. Delegated agents carry a scope inherited from their controller, and revocation cascades.
• Terms enforced in consensus. A delegated agent acts within terms recorded on chain (per-transaction, hourly and daily spend limits, allowed operations, counterparties and chains, expiry), and every validator checks each action against them.
• Owned, funded agents. An agent can never spend more than its owner funded; the owner can pause it, reclaim unspent funds at any time and grant refill allowances that always expire.
• Signed agent requests. Every HTTP request an agent sends through its serving node carries an RFC 9421 signature made with a key held in that machine's TPM, so a server off the network can resolve the agent, its root identity, the terms in force and whether it is revoked or quarantined.
• Evidence packs. Agent audit logs are committed on chain each epoch, and an evidence pack (audit entries, mandates, oversight records, receipts, the models called) can be verified offline from the chain's genesis anchor. The pack maps its sections to EU AI Act Articles 12 and 14 and to ISO/IEC 42001 controls. The governed audit retention floor is 183 days.

The network is live in preview; governance decides the steps to testnet and mainnet. See tenzro.com.