40% of enterprise apps will embed agents by year-end. Most teams shipping one haven't built the governance to match
Gartner projects 40% of enterprise apps will embed AI agents by 2026. The governance checklist: scoped credentials, audit logs, confirmation gates, rate limits.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
Gartner’s forecast that 40% of enterprise applications will feature task-specific AI agents by the end of 2026 — up from under 5% in 2025 — has been quoted constantly this year, usually as an adoption story: agents are here, get on board. That’s the less useful half of the number. The more useful half is what it implies about governance debt: a five-fold jump in one year means most of those agents are getting shipped by teams that have never operated an autonomous system in production before, on a timeline that doesn’t leave much room to build the operational discipline around it after the fact.
If your team is one of the ones shipping an agent-embedded feature this year, the adoption stat isn’t the interesting part. The governance checklist is.
Why “it’s just a feature” undersells the risk
An agent embedded in your product is not the same engineering problem as a new UI feature, even when it looks like one from the roadmap. A traditional feature does exactly what the code says, every time. An agent decides, at runtime, which of the tools available to it to call and in what order — which means the failure modes aren’t “a bug shipped,” they’re “the agent did something technically within its permissions that nobody anticipated.” That distinction is exactly why OWASP’s GenAI Security Project stood up a dedicated Top 10 for agentic applications at the end of 2025: the risk categories that matter for an agent — tool misuse, identity confusion, cascading failures across chained actions, a human approving something they were talked into rather than something they actually understood — don’t map cleanly onto a normal web-app threat model.
What this looks like when it goes wrong
Take a support agent given tool access to “resolve tickets” — read the account, check the order history, issue a refund if the complaint looks valid. On paper that’s one feature. In practice it’s a chain of decisions: the agent decides whether the complaint is valid, decides what “valid” means from the ticket text alone, and decides how much to refund, all without a human seeing the reasoning until after the money has moved. A scoped credential limits what the agent can touch — it can’t also delete the account or change the customer’s email — but it doesn’t stop the agent from being confidently wrong about a refund it was allowed to issue in the first place. That’s what the confirmation gate is for: not blocking the agent from doing its job, but making the one irreversible step in an otherwise-automated chain require a person to actually look at it before it fires. Teams that skip the gate to keep the interaction “fully automated” usually find out why it mattered the first time an ambiguous ticket gets resolved fast, confidently, and wrong — and by then it’s a chargeback dispute or an angry customer thread, not a code review comment somebody could have caught for free.
The checklist
None of this requires exotic tooling. It requires deciding, before the agent ships, what its blast radius is allowed to be and building the plumbing to enforce and observe that — rather than discovering the answer from an incident report.
Four things to have in place before an agent touches production
Scoped credentials, not your app's admin key
Give the agent a credential that only grants what its actual job requires — the resources it needs to read or write, nothing else. If your platform doesn't support fine-grained scopes yet, the fallback is a dedicated credential per agent rather than sharing one broad key across every automated caller, so a compromised or misbehaving agent's reach is bounded and attributable.
Audit logging with enough context to answer 'why'
A log line that says 'agent called delete_record' is close to useless after the fact. Log the input that triggered the decision, the tool calls made, and the output — enough to reconstruct why the agent did what it did, not just that it did something. This is the single most-cited control across both the OWASP guidance and Singapore's IMDA framework, and it's the one teams skip first when they're moving fast.
A human-confirmation gate on anything consequential
Reading data, drafting a suggestion, or proposing a plan is low-stakes even if the agent gets it wrong. Sending, deleting, paying, publishing, or changing a permission is not. Draw the line explicitly per action type — not per feature — and require a real confirmation step for anything on the consequential side, one an agent can't route around by rephrasing its own request.
Rate limits sized for a machine, not a human
A human clicking through a UI is naturally rate-limited by how fast they can click. An agent isn't — a bug, a bad prompt, or a compromised session can turn one agent into thousands of requests per second, which is exactly the failure mode API teams have started naming as their top new operational worry now that agent traffic is a real share of total calls. Rate-limit per credential, and make the limit tight enough that a runaway loop fails loudly and cheaply instead of quietly at scale.
What “governance” doesn’t mean here
None of this is a call to slow down or gate every agent feature behind a review committee. It’s the opposite case: the four items above are cheap to build in relative to the feature itself, and they’re what let you ship an agent-embedded feature faster with confidence, because you’re not gambling that nothing goes wrong — you’re building the system so that when something does, you can see it, bound it, and explain it. Gartner’s own roadmap has agents getting more autonomous and more interconnected every year through 2029; a team that treats this year’s task-specific agent as practice for that trajectory, rather than a one-off feature, is in a much better position when the next stage — agents collaborating with other agents — shows up on the roadmap too.
Agent governance FAQ
Does a read-only AI agent need this same governance checklist?
Less of it, but not none. A read-only agent doesn't need a confirmation gate on every call, but it still needs a scoped credential limited to read access on only the resources it's meant to see, audit logging so you can tell what it looked at if its output turns out to be based on data it shouldn't have had, and a rate limit. The confirmation gate is specifically for actions with real-world consequences — reading has none, until the agent starts drafting something a human acts on without checking.
Who inside the team should own this — security, engineering, or product?
Whoever owns the credential should own the inventory and rotation, usually engineering or platform. Whoever defines what counts as a consequential action for the confirmation gate should be product, because that's a product decision, not a security one. Security should own the audit-log review process. Splitting ownership like this is normal — the mistake is having no owner at all for any one of the four pieces.
We already shipped an agent without any of this in place. Where do we start?
Audit logging first, even retroactively — turn it on today so you at least have a trail going forward. Then add a confirmation gate on the single highest-blast-radius action the agent can take, even if it's the only one you gate at first. Scoped credentials and rate limits matter, but they're prevention; logging and the gate are what let you catch and contain a problem you're already exposed to.
For anyone building agent-facing tooling on top of Norbelys specifically, scoping the API key you hand an agent and the guardrails worth putting around an AI operator sending on your domain cover the credential and confirmation-gate pieces of this checklist in more platform-specific detail: Norbelys’s MCP server issues an org-scoped key per integration rather than one shared credential across every agent you connect, and an AI operator drafting or sending through Norbelys sits behind the same kind of human-confirmation gate this checklist describes — not blanket autonomy on the one action category that actually matters, the send. The governance work is the same shape regardless of which platform’s agent you’re shipping — the credential, the log, the gate, and the limit are the four things worth having before the feature, not after the postmortem.