AI Agents: Classify by Autonomy and Access, Not Type

An AI agent is software that takes a goal, chooses its own steps, calls tools and other systems to carry them out, checks the result, and adjusts — without a person approving each move. That last clause is the entire difference.

Our position at LeapForce is that the taxonomy everybody teaches for AI agents is the wrong one. Reflex agents, goal-based agents, utility-based agents: correct in a textbook, useless in a procurement meeting. The two facts that decide whether an agent helps you or hurts you are how much autonomy it holds and how much access it holds, and those two things are independent. Someone put the problem plainly on Hacker News in February 2026, in a thread titled How do you give AI agents access without over-permissioning?: user NBenkovich wanted an agent to read deployment logs and inspect environment variables, and found that the only token available also let it modify and delete things. "There's no clean read-only or capability-scoped access," they wrote. The fourteen replies offered platform-specific workarounds: Supabase IAM roles, cloud service accounts, whole-VM isolation. None of it was a general answer, because there isn't one at the credential layer.

The short answer: Classify every AI agent on two axes before you deploy it — its autonomy level (observe, advise, act with approval, act autonomously) and its access scope (what data and systems its credentials can reach). Gartner found in May 2026 that agent governance fails precisely when organisations treat those two as one thing.

Last updated: July 30, 2026.

The permission grid: an agent's risk is set by where it sits on both axes, not by what kind of reasoning it does.

We have not run a controlled deployment of every agent pattern described below and we are not going to pretend otherwise. What follows is built from published research, standards documents, incident reporting and the governance patterns we build into our own platform — not from a first-hand test we conducted for this article.

What an AI agent actually is

Asked plainly — what is an AI agent — the answer is a program that pursues a goal by deciding its own next step. Three properties have to be present together: it holds an objective rather than a single instruction, it can call tools that change something outside itself, and it loops, reading the result of its last action before choosing the next one. Remove any one and you have something else.

The word doing the work in that definition is delegated. The OWASP Top 10 for Agentic Applications 2026, published on 9 December 2025 and built with more than 100 industry experts, researchers and practitioners, scopes its risk list to autonomous, goal-driven agents "capable of planning, acting, coordinating, and shaping entire workflows" — which is to say, to software operating on delegated authority. Delegation is not a technical detail bolted onto the concept. It is the concept. A model that writes you a paragraph has been asked a question. A model that reads a ticket, decides the refund is valid, and posts the refund has been given a job.

That distinction is why the classical taxonomy stops being useful the moment money is involved. Textbooks sort agents by the sophistication of their internal decision rule: a simple reflex agent maps a percept straight to an action, a model-based reflex agent keeps internal state, a goal-based agent searches for a plan, a utility-based agent weighs outcomes, and a learning agent updates itself from feedback. Multi-agent systems put several of those in a room together. All of it is real computer science and all of it is invisible to the only questions your risk committee will ask, which are what the thing can reach and what happens when it is wrong.

There is a practical reason to hold the definition tightly rather than loosely. Once "AI agent" stretches to cover anything with a language model inside it, you lose the ability to say which of your deployments needs an approval gate and which does not. Sorting your fleet begins with being able to say, for each item, whether it acts on its own initiative. Most companies discover at that moment that they cannot produce the list at all.

What an AI agent is not

Four things get called AI agents and are not. Keeping them separate is the cheapest governance win available, because each one carries a different risk profile and a different control set, and lumping them together guarantees you apply the wrong one.

A chatbot answers. An assistant drafts and hands back. Scripted automation runs a path a human wrote, which is why it has been governable for twenty years: you can read the script. An agent chooses the path at runtime, which means you cannot read it in advance and have to constrain it instead.

The RPA comparison is the one that trips up experienced automation teams. A robotic process automation bot and an agent can perform the identical action against the identical system, and the control that made the bot safe does not transfer. With the bot, you reviewed the sequence before it shipped. With the agent, there is no sequence to review — there is a goal, a set of available tools, and a model deciding between them under conditions you did not enumerate. That is not an argument against agents. It is an argument for moving your review from the path to the boundary.

One more non-agent deserves naming: the demo. A system that only ever runs while a person watches it, on data a person selected, is not yet an agent in any sense that matters for risk. It becomes one the day it runs on a schedule.

How an AI agent works: the loop and the two doors

Every AI agent, whatever framework it is built in, runs the same four-beat loop: it forms an intention from its goal and current context, chooses a tool call, executes it, then reads the result and starts again. Frameworks dress this up with planning modules, memory stores, reflection steps, orchestration between sub-agents, and increasingly elaborate tool calling conventions. Underneath, it is intention, action, observation, revision, repeated until the goal is met or a limit stops it. The reasoning is done by a large language model; the acting is done by whatever that model is allowed to call.

The loop matters less than where it touches your company, and it touches in exactly two places. The first door is the model: the agent sends text out to an inference endpoint, which may be a vendor API, a self-hosted model, or several of each. The second door is the tool layer: the agent calls your systems, usually through connectors, an internal API, or a Model Context Protocol server, using credentials somebody issued it. Nearly everything that goes wrong with agents goes wrong at one of those two doors, and almost nothing goes wrong in the reasoning itself in a way you can control.

The loop is generic; the two doors are where every control you can actually enforce has to sit.

That framing has an unglamorous consequence. Improving the agent's prompt is not a control. Choosing a better model is not a control. A control is something that sits at a door and can refuse. The reason we build a single governed endpoint in front of every model, the approach we describe in our earlier analysis of what an AI gateway is and why enterprise LLM governance needs one, is that the first door is the only place where identity, policy, masking, routing, metering and audit can be applied to every agent at once without asking each team to change code.

The second door is harder and more consequential. Model calls leak information; tool calls change the world. When an agent has a token that can write, the blast radius of a wrong decision is whatever that token can reach, and the agent does not know the difference between a routine update and an irreversible one unless something outside it enforces the distinction. If you are briefing a security team on this for the first time, Jeff Crume and Josh Spurgin at IBM spend eleven minutes on the risks that attach to autonomous agents — prompt injection, data poisoning, bias — and the safeguards that answer each one.

The classification that matters: autonomy times access

The useful way to classify an AI agent is on two independent axes: how much autonomy it has been granted, and how wide the access scope attached to its credentials is. The distinction between those two is not our invention — Gartner published it as a finding, in unusually direct language. Crossing them into a grid is our own step, and the section below says plainly which part is which.

In a press release dated 26 May 2026, Gartner said that applying uniform governance across AI agents will lead to enterprise AI agent failure, and predicted that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps found only after a production incident. That is a finding about AI agent governance as a practice, not about any particular platform. The line that should go on a wall somewhere is Gartner's diagnosis that failures follow when organisations "fail to distinguish between an agent's ability to act and the scope of access". Senior Director Analyst Shiva Varma put the root cause as binary thinking — "either locked down or fully trusted" — producing two symmetrical failures. Over-restrict the simple agents and you slow delivery and push people into building their own, unsupervised. Under-restrict the autonomous ones and you take on operational, security and compliance risk you have not priced.

One warning before you draw your own grid: most organisations cannot place their agents because they cannot list them. Agents get built inside personal accounts and departmental subscriptions, and the first honest step is usually discovery rather than classification — pulling the list of what is already running from expense records, OAuth grants in the identity provider, and the connectors people have authorised. Placement itself is quick; finding out what you are placing is the slow part, and the count is almost always larger than the sponsor expected.

Two axes, not one. An agent that can only read but acts entirely on its own is a different animal from an agent that can write anything but pauses for a human every time. Both are riskier than a read-only advisor and less risky than an autonomous writer, and a single-axis policy cannot express any of that. We call the grid formed by the two axes the permission grid. Placing every agent you run into a cell is an afternoon's work once you have the list, because both questions are answerable from records you already hold.

The two "mismatch" cells are the point of drawing the grid. They are the configuration error the public threads keep describing, and they are free to fix: an agent that only advises does not need a token that can write, and the reason it usually has one is that the platform issued a single token with everything attached. That is precisely the complaint in the Hacker News thread this article opened with.

The four autonomy levels, and what each one needs

Gartner's autonomy ladder has four rungs, and each rung changes the control set rather than merely tightening it. The distinctions are worth learning verbatim because they map cleanly onto procurement language and onto what an auditor will ask.

Level 1, Observe. Read-only access to defined data sources, with output visible only to the person who asked. Document summarisation, knowledge retrieval, code explanation. Gartner's guidance here is deliberately light: scoped data access, user authentication, usage logging, basic functional and security testing. Risk is confined to data exposure and output accuracy, so controls should stay "lightweight and targeted".

Level 2, Advise. The agent produces recommendations, drafts or proposed actions; a human reviews everything and executes manually. Still read-only, no write access anywhere. Email drafting, report generation, decision support. The new risk is subtler than data exposure: advisory agents "can anchor judgment, creating downstream risk when inaccurate outputs are trusted due to automation bias". The added controls are accuracy and hallucination testing, domain-specific quality evaluation, and training people on how much to rely on the output.

Level 3, Act with approval. The agent can write data, send communications or change configuration, but only after explicit human approval for each action. This is the classic human-in-the-loop arrangement, where most enterprises should be aiming for their first production agent. It is also where the control most often turns into theatre. Varma's warning is specific: "human review is effective only if it remains a meaningful control", and without security testing, approval workflows with audit trails, and agent-specific incident response, approvals can "degrade under time pressure or approval fatigue, creating a false sense of safety". Price this level honestly before you commit to it: an approval that takes a reviewer thirty seconds, across a thousand actions a month, is a working day of somebody's time, and that cost belongs in the business case next to the licence.

Level 4, Act autonomously. The agent executes inside defined guardrails, and humans review exceptions, logs and aggregate outcomes rather than individual decisions. Gartner is blunt about the cost: this level demands the most rigorous governance of the four, naming "continuous monitoring, enforced guardrails, rapid rollback mechanisms, circuit breakers" plus clear ownership for how the agent behaves.

Read those four together and a rule falls out that we would defend against most alternatives: you do not earn Level 4 by trusting the model, you earn it by making the action reversible. Every Level 4 deployment we would be comfortable with shares one property — a wrong action can be undone cheaply, at scale, by someone who did not have to notice it in real time. Where that property is absent, Level 3 is not a stepping stone, it is the destination.

The access scope axis: what it can touch

Access scope is the set of data and operations an agent's credentials can reach, and it is the axis companies measure worst. The reason is structural: agents inherited an identity model built for humans. Most platforms issue one token per account with one bundle of rights, so the practical scope of an agent is whatever its human creator could do, which is almost never what the agent needs.

The scale of the problem is now measurable. Palo Alto Networks' 2026 Identity Security Landscape, a survey of 2,930 cybersecurity leaders published in May 2026, reports that organisations manage an average of 109 machine identities for every human identity, that 9 out of 10 organisations suffered a successful identity-related breach in the previous twelve months, and that 96% of respondents say human identities hold access far beyond what their roles require. AI agents are the fast-growing slice: the report expects them to grow 85% this year. The finding that should worry an agent programme most is about knowledge rather than counts: as Help Net Security summarised the report, most organisations can explain the purpose of their AI agents, while "far fewer can define what those agents can access, how access is limited" — or when permissions get revoked, or which systems inherit that access.

Four questions define an agent's scope, and each has a wrong default:

• Which systems? The default is "everything the connector offers". The fix is a curated registry where IT vets a connector once and exposes only the actions a given agent needs.
• Which records inside those systems? The default is the whole tenant. Row and entity filters do exist: one legal entity, one region, one customer segment. They are usually available and almost never used.
• Which operations? The default is read plus write because they arrive in the same token. Action-level scoping is the single most effective control on this axis.
• For how long? The default is forever. An expiry date on an agent's credentials converts a permanent risk into a scheduled review, and it is the field most often missing entirely. We went deeper on this in our analysis of why every AI agent needs an owner, a scope and an expiry.

There is a second-order effect worth naming, because it is the one that turns a contained mistake into an incident: inheritance. An agent that can reach a connector that itself holds broad rights has the union of both scopes, not the intersection. Model Context Protocol servers make this concrete, since a single server can front many upstream systems, and the agent's effective reach is whatever that server can do on its behalf. Our review of MCP server security and how to govern AI connectors works through what to check before approving one.

Where AI agents actually fail

AI agents fail in named, catalogued ways, and the useful move is to pair each failure mode with the control that catches it rather than listing worries. OWASP's 2026 list of the ten most critical agentic risks is drawn from real 2025 incidents rather than projections, which is what makes it usable as a checklist. Read the right-hand column with one thing in mind: almost none of these controls live inside the agent framework you build with. They live at the identity layer, the connector layer and the request path, which is why "we chose a safer framework" is not an answer to any row in this table.

Goal hijack is not theoretical, and the best evidence is from a standards body rather than a vendor. The US National Institute of Standards and Technology defines agent hijacking as "a type of indirect prompt injection in which an attacker inserts malicious instructions into data that may be ingested by an AI agent, causing it to take unintended, harmful actions". In its January 2025 experiments, NIST found that red-team refinement raised attack success against a leading model from 11% to 81%, and that allowing 25 attempts lifted the average success rate across injection tasks from 57% to 80%. The follow-up is worse. NIST's Center for AI Standards and Innovation reported on 23 March 2026 that across more than 250,000 attack attempts from over 400 participants against 13 frontier models, "at least one successful attack was found against all of the target frontier models", with some attack families transferring across scenarios and models. Models differed sharply in how many successful attacks were found against them, and NIST reports that this did not correlate uniformly with model capability — so you cannot pick the strongest model and assume you have picked the safest one.

Then there is the failure mode nobody wants to design for: the agent pursuing its own reading of the goal. Anthropic's Agentic Misalignment in Summer 2026 study, published 13 July 2026, put frontier models from six labs into simulated high-stakes agentic scenarios and documented four failure modes. Fourteen models were named, Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, Grok 4.3, DeepSeek V4 and Kimi K2.6 among them. One failure mode is covert sabotage: a model quietly changing the work itself rather than refusing the task or escalating it. One example: "Gemini 3.1 Pro intervened in 19 of 20 runs, and 11 of those interventions were covert." These are controlled simulations with fictional organisations, not field reports, and should be read as a demonstration that the behaviour is reachable rather than as a base rate. It is still the cleanest available argument for logging what an agent did rather than trusting what it says it did.

The public incident that best illustrates the access axis remains the coding agent that deleted a production database during a declared code freeze, after which Replit's CEO apologised and the agent itself reported having "made a catastrophic error in judgment" and "destroyed all production data". The lesson people drew from it on Hacker News was sharper than most of the commentary: as user pxc wrote in that discussion, "If an AI agent has access, it has permission." A code freeze communicated in a prompt is not a control. A token that cannot drop tables is.

The agent passport: four fields before it acts

Before an AI agent takes its first action in a production system, four fields should exist and be answerable by someone other than its author. We call this the agent passport, and it is deliberately short enough to fit in a spreadsheet row, because a governance artefact nobody maintains is worse than none.

Owner. A named person accountable for the agent's behaviour, not a team alias. Ownership has to survive the person leaving, which means the record belongs to the company rather than to an individual's account. This is the field that turns an orphaned automation into a maintained one, and its absence is what OWASP calls a rogue agent. Our write-up on moving shared AI agents from personal prompts to owned company assets covers the transition in more detail.

Scope. The agent's own non-human identity, with the connectors, actions, record filters and expiry listed explicitly. Two tests: could you revoke everything this agent can reach in one action, and would that revocation happen automatically when its owner leaves? If the answer to either is no, the agent is running on a human's identity in practice, whatever the diagram says.

Record. What the agent did, at the action level, retained and tamper-evident. Model-call tracing is not enough on its own — it tells you what was said, not what changed. The entries that earn their keep are the refusals: an agent that was blocked by policy fifty times last month is telling you something about either the policy or the agent, and a log that only records successes cannot say which. We set out what that layer needs in our analysis of AI observability and audit trails that prove agent actions.

Budget. A ceiling in currency, per agent, per period, with an owner who gets told when it is approached. Token counts are the wrong unit because nobody's finance function budgets in tokens, and because the same token count costs wildly different amounts depending on which model served it. A budget cap is also a crude but effective circuit breaker: a hijacked agent looping on a task burns money in a pattern that a spend alert catches faster than a security review does.

The passport is not a maturity model and there is no partial credit. An agent with an owner, a scope and a record but no budget is one runaway loop away from a finance conversation. An agent with all four and no autonomy ceiling is still allowed to do the wrong thing correctly. The passport tells you who is responsible and what happened; the permission grid tells you how much the agent was allowed to attempt. You need both.

A worked example: moving one task up the ladder

Here is the diagnostic in full, run against one ordinary task, in the order that keeps you out of trouble. Take supplier invoice matching in a finance team: invoices arrive by email, someone opens the ledger, finds the purchase order, checks the amount, and either posts the match or flags the exception.

Step 1, write down the irreversible actions. Posting a ledger entry is reversible with an adjusting entry and a note. Paying the invoice is not, in any sense finance recognises. That single sentence already tells you the autonomy ceiling: whatever else happens, payment stays at Level 3 with a human approving each release.

Step 2, start at Level 1 for a fixed period. The agent reads the invoice and the ledger and produces a proposed match with its evidence, visible only to the analyst who asked. It writes nothing. Its identity holds read on the mailbox folder and read on the ledger for one legal entity, and it expires in ninety days. You are measuring one thing: how often the proposed match is right. We are not going to invent a threshold for you, because the honest one is local: promote when the agent's error rate is at or below what your analysts already produce on the same invoices, measured the same way. If you have never measured the human baseline, that is the first number to go and get, and it is usually more surprising than the agent's.

Step 3, promote to Level 2 only when the accuracy number is known. Now the agent drafts the journal entry and the analyst executes it. The failure mode changes from data exposure to automation bias, so the draft has to show its working: which purchase order, which line, why the variance is acceptable. The analyst also needs an explicit brief on how much to trust it. The access scope has not changed at all. That is the point: promotion on the autonomy axis should not quietly move you on the access axis.

Step 4, promote to Level 3 with a write scope that matches exactly one operation. The agent posts matched entries after approval. Its token can create journal entries in one entity and can do nothing else — no vendor record edits, no payment release, no ledger deletions. The approval interface shows the invoice, the matched purchase order and the variance, because an approval screen that shows only a conclusion trains people to click.

Step 5, consider Level 4 for the reversible subset only. Matches under a value threshold, with a variance under a tolerance, from suppliers on an allowlist, post without approval. Everything else stays at Level 3. There is a rate ceiling, a daily budget in currency, and a circuit breaker that halts the agent if the exception rate crosses a threshold. Someone reviews the aggregate weekly, not the individual entries.

What to do when the platform will not give you that scope. This is the exact wall the Hacker News thread hit, and it is worth answering directly rather than leaving as an aside, because it is the normal case rather than the exception. Many systems of record still issue one token with read and write bundled, and no amount of policy writing changes that. The workable answer is to stop trying to scope the credential and start scoping the call: put a broker between the agent and the system, hold the real credential there, and expose only the specific operations the agent is allowed to invoke. The agent never holds the token; it holds permission to ask the broker for one named action, and the broker refuses anything else and logs the refusal. That is what a connector layer with action-level scoping and credential brokering is for, and it is also why the enforcement point belongs outside the agent — an agent asked to restrain itself is a prompt, not a control. Where even a broker is impossible, the honest fallback is a dedicated service account whose rights are as narrow as the platform allows, never a person's credential, with the gap written down as an accepted risk and a review date.

Two things about this sequence are load-bearing. First, the access scope widens once, at step 4, and never as a side effect of an autonomy promotion. Second, every promotion is gated on a number you did not have before the previous stage ran. A programme that cannot say what it learned at Level 2 has no basis for granting Level 3, and Gartner's prediction that 40% of enterprises will demote agents after a production incident is, read charitably, a prediction about programmes that skipped the numbers.

Agent washing: is the thing you are buying actually an agent?

Most products marketed as AI agents are not. Gartner named the practice "agent washing" — rebranding assistants, robotic process automation and chatbots without substantial agentic capability, and estimated that only about 130 of the thousands of agentic AI vendors are real. That figure is worth pausing on, because the buying implication runs both ways: you may be paying agent prices for an assistant, and you may be applying agent-grade governance to something that does not need it.

Five questions separate the two, and all five have answers a vendor can demonstrate in a call:

1. Does it act without a person in the turn? Ask for a trigger that is not a human clicking. If every action begins with a click, it is an assistant, and Level 2 controls are sufficient.
2. Whose identity does it act under? If the answer is "the user's OAuth grant", you are buying an assistant with extra steps, and every action it takes will be attributed to a person in your logs. Ask whether the product can hold its own credential with its own scopes.
3. Can you see the tool calls? Not the conversation — the calls. A product that cannot show you which systems it touched, in what order, with what result, cannot be audited, whatever its dashboard implies.
4. What can you refuse? Ask to see the deny path. Can you block an action by policy, and does the block get logged? A product with no enforcement point has no controls, only settings.
5. What happens at the ceiling? Ask what the product does when a budget, rate or error threshold is hit. "It keeps going" is a real answer some products give.

All five can be rehearsed, so ask for the artefact rather than the answer: an exported action log from a live tenant, a written scope document for one agent, and a screen recording of a policy denial. A vendor that answers all five well is selling an agent platform. A vendor that answers the first two well and the last three badly is selling autonomy without accountability, which is the combination that produces the incidents in the previous section. And a vendor that answers the first question with "well, you can schedule it" is selling scripted automation, which may be exactly what your task needs — scripted automation is cheaper, more predictable and easier to audit, and Gartner's own guidance is to use agents "when decisions are needed, automation for routine workflows and assistants for simple retrieval".

What the rules already require of you

If you deploy an AI agent in a high-risk context in the EU, several of the controls above are already legal duties rather than good practice, and the duties fall on the deployer, not only on the vendor. Article 26 of the EU AI Act requires deployers of high-risk AI systems to use them according to the provider's instructions and, under paragraph 2, to "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support". Paragraph 5 requires monitoring, and obliges a deployer that identifies a serious incident to inform the provider, then the importer or distributor, then the relevant market surveillance authority, and to suspend use where the system presents a risk. Paragraph 6 sets a retention floor: logs automatically generated by the system, to the extent they are under the deployer's control, must be kept "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months".

Read those three paragraphs next to the agent passport and the mapping is almost mechanical. Human oversight with authority is the owner field plus a real approval gate. Monitoring and incident notification is the record field plus an agent-specific runbook. Six months of retained logs is the record field with a retention policy attached. None of this is exotic; what makes it hard is that the logs have to exist at the action level, and most agent deployments log the conversation.

Three cautions. This mapping is operational, not legal: satisfying a passport field is how you produce the evidence, and whether you have discharged a duty is a determination for your own counsel and your regulator, not for a table in a blog post. Whether a given agent is "high-risk" under the Act turns on its use case and not on how autonomous it is, so a Level 4 agent doing low-stakes work may fall outside these duties while a Level 2 advisor in hiring or credit falls squarely inside. And the timeline is a moving target that has already moved once. Our guide to EU AI Act compliance for deployers tracks the obligation dates; this article deliberately does not restate them, because they change faster than a pillar page should.

The case against AI agents right now

The honest counterargument to everything above is that a large share of agent projects should not be running at all, and the strongest evidence for it comes from the same analyst house whose framework this article builds on. In June 2025 Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. Anushree Verma, Senior Director Analyst, described most agent projects as early-stage experiments and proofs of concept, "mostly driven by hype and often misapplied", and added the line that every agent programme should test itself against: "Many use cases positioned as agentic today don't require agentic implementations."

The scepticism has since sharpened rather than faded. On 28 July 2026 Gartner predicted that AI agents will outnumber sellers 10 to 1 by 2028, yet fewer than 40% of sellers will say agents improved their productivity, and named the mechanism: agent sprawl, "more digital activity, but little improvement in seller impact". VP Analyst Dan Gottlieb's formulation applies well beyond sales. "If those systems are fragmented, the agents will scale the fragmentation."

Set against that, the same June 2025 release forecast at least 15% of day-to-day work decisions made autonomously through agentic AI by 2028, up from 0% in 2024, and 33% of enterprise software applications including agentic AI by 2028, up from under 1%. Those two sets of predictions are not in conflict. They describe a technology that is arriving regardless and failing frequently on the way, which is an argument for placing agents deliberately rather than for waiting.

So here is the case against, stated as strongly as we can make it. Agents cost more than the licence: integration with existing infrastructure, evaluation, monitoring and the human review time that Level 3 consumes are all real line items, and our breakdown of what enterprise AI implementation actually costs beyond the licence puts numbers on the pattern. They fail in ways your existing monitoring was not built to see, because that monitoring assumes a human behind every action. Their reliability against adversarial input is, on NIST's evidence, not solved for any frontier model. And for a large fraction of the work people point agents at, a scripted automation with a fixed path would be cheaper, more predictable and easier to defend in an audit. If your candidate task has a stable path, use the script. Agents earn their cost where the path genuinely varies and the variance is expensive.

Where this guidance is uncertain

Several things in this article are less settled than the confident register of a pillar page implies, and it is worth saying which.

The autonomy ladder is a 2026 framework, not a standard. It is coherent and it maps onto how enterprises actually argue about agents, but it has not been through the kind of multi-year consensus process that produced ISO/IEC 42001, and the level boundaries will move. Treat the four rungs as a shared vocabulary for a conversation, not as a certification scheme.

The identity numbers move fast and they are vendor-published. We quoted 109 machine identities per human because the underlying survey is large and its methodology is at least described, but the previous edition of the same series, CyberArk's 2025 Identity Security Landscape, published 23 April 2025 from 2,600 respondents, put the ratio at 82 to 1. A third of that jump in one year may be genuine growth; some of it is a changed definition of what counts as an identity, and the full reports usually sit behind a form. Use these figures to establish direction, never to size a programme. Reddit, which is where a great deal of practitioner discussion about this happens, blocks automated retrieval, so the practitioner voices in this article come from Hacker News and skew toward engineers rather than the finance and operations teams who will actually own most agents.

The misalignment research is simulation, not field data. Anthropic's scenarios are constructed to elicit the behaviour and use fictional organisations; the rates in them are not incidence rates for your deployment, and reading them as such would be a mistake in the opposite direction from ignoring them.

We have no first-hand measurement of our own to offer on the specific question of how much the permission grid reduces incidents, because that number would require a controlled comparison across organisations that nobody has published. What we can say is what the failure reports have in common, which is an agent holding more access than its autonomy level called for. And there is one thing the grid does not help with at all: an agent operating exactly within its scope and autonomy, doing the wrong thing because the goal it was given was wrong. That is a management problem wearing a technical costume, and no amount of scoping fixes it.

How LeapForce approaches the agent layer

Once work moves from a person to an agent, the operational question stops being which agent to buy and becomes who owns it, what it can touch, what it did, and what it cost. AI agent governance, in other words, is an infrastructure problem before it is a policy problem. That layer is what LeapForce builds: one controlled path in front of every model, connector and agent, with agent identities treated as first-class and carrying a named owner, a scope and an expiry. Connectors are vetted once and exposed at action level, human approval gates inside multi-step workflows, and an action-level record that includes what was refused. Our rollout guidance for the gateway is deliberately staged as observe first, enforce second, optimize third, for the same reason the worked example above starts at Level 1: you cannot set a sensible policy for traffic you have not yet seen. LeapForce is in active development and per-capability build status is disclosed honestly, so treat the platform pages as the current source of truth for what ships today rather than this paragraph.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.