Put the Control Where the Call Happens

Buy an agent observability platform today and you get something genuinely good. Reasoning steps become spans. Tool calls carry latency and token cost, and if you switch on content capture, the arguments too. You can replay a session, diff two runs, chart spend by agent. Sit in front of that dashboard while an agent works and you can follow it almost in real time.

Including the part where it does the wrong thing.

That is not a criticism of the tools. It is a description of what they are for. A span brackets an operation. It opens before the call, it closes after, and at no point in its life can it return a verdict. The tracing API has no deny. It never had one, because nobody asked it for one.

For a model that returns a prediction, that costs you nothing. The wrong answer is a wrong number sitting in a response body, and you can throw it away. For an agent, it is the whole problem. The output is not a number. It is a payment, an email, a closed ticket, a deleted row.

You cannot un-send the email by looking at the trace of it.

What AgentOps became

The term has a real lineage. MLOps made model deployment repeatable. LLMOps adapted that to prompts, context, and non-deterministic output. AgentOps was the next step, and the early definitions are more specific than the marketing suggests.

The earliest academic treatment, a 2024 taxonomy from CSIRO Data61 built by surveying the AgentOps tools that already existed, frames it as an observability discipline: trace the right artifacts across the agent lifecycle so stakeholders can understand the agent, detect anomalies, and prevent failures. Read the verbs. Understand, detect, prevent. Two of the three are about knowing. The third is what everyone assumed came free with the first two.

The market built the knowing part. It built it well, and then it sold it as the whole discipline.

It is worth knowing what that layer stands on. OpenTelemetry's GenAI semantic conventions are the closest thing to a portable schema for agent traces, and they now live in their own repository. I audited it on 14 August. There are 188 stability markers across the convention model files. Every one reads development, OpenTelemetry's least mature tier. There are no published releases. The README section for the schema URL says TODO.

None of that is a knock on the working group, who are doing careful work on a hard problem in the open. It is a knock on anyone selling a finished agent operations product on top of it. The measurement layer under the category is 188 for 188 pre-stable.

The asymmetry nobody prices

Here is the structural point, and it survives every improvement anyone makes to tracing.

An agent decides to call a tool. Arguments get bound. The call goes out. Something happens in a system that has consequences. The span closes around it, carrying the outcome, and lands in your dashboard accurate and complete and too late.

There is a slot in that sequence, between the call being formed and the action taking effect, where a system could ask whether this particular call, from this particular agent, acting for this particular person, is allowed to proceed. In most deployments that slot is empty. Not badly implemented. Empty. There is no subject to check, no scope to check it against, and no budget to decrement.

So the agent gets the benefit of the doubt on every call it makes, and the operations layer records the consequences with excellent fidelity.

This is why the category feels simultaneously mature and useless during an actual incident. The traces are superb. They tell you exactly how you got here. They had no opinion on whether you should come.

Most of this is your own agent

Gartner's forecast is that through 2028, at least 80% of unauthorized AI agent transactions will come from internal violations of enterprise policy, things like information oversharing, unacceptable use, and misguided agent behaviour, rather than from malicious attacks.

That inverts the standard security posture. Four out of five unauthorized agent actions will not involve an adversary. They will be your agent, running your prompt, using a tool you gave it, doing something you would not have approved if anyone had asked you. No breach. No intrusion. No alert, because nothing anomalous happened at the network layer. The agent did exactly what it was permitted to do, and it should not have been permitted.

Threat detection is looking for the wrong thing here, because most of the time there is no threat to find. What catches this is a boundary that knows what the agent is for.

The risk list points the same way. The OWASP GenAI Security Project published its Top 10 for Agentic Applications in December 2025, built with over a hundred contributors. I classified the ten by one question: which control most reliably prevents this risk, as opposed to reporting it? Primary control here means the mechanism whose absence most reliably turns the risk into an incident.

Three are static problems, fixed before the agent runs. Sandbox the code execution, pin and verify the supply chain, authenticate the channel between agents. Good engineering, well understood, and none of it needs a new discipline.

Six are decided at the call. Goal hijack, tool misuse, identity and privilege abuse, memory poisoning, cascading failures, rogue agents. Several of those are adversarial, and the attacker is real. What determines whether the attack lands is still whether something checked the request before it went through.

One I would argue about, and it is the most interesting row. Human-agent trust exploitation, where a persuasive explanation talks a person into approving something harmful, has no good boundary control, because the human is the boundary. You catch it by noticing patterns afterwards, or you design the interface so the agent cannot manufacture consent in the first place. If you think that belongs in a different column, say so, because I am not certain either.

The classification is mine rather than OWASP's, and most of these have a secondary control elsewhere. But the shape holds: none of the ten are primarily controlled by a dashboard.

The research already moved to constraint

Since that 2024 taxonomy, the centre of gravity in the research has moved from watching agents to constraining them. What follows is preprints rather than settled consensus, but the direction is consistent enough across independent groups to read as a signal. Progent introduced a policy language for fine-grained privilege control at the tool call. SkillScope pushed the same idea down to individual skills and then went looking for the problem in the wild, validating 7,039 skills that exhibited over-privileged behaviour. Its framing is the part worth stealing: the same action can be necessary under one user prompt and over-privileged under another. Privilege is not a property of the tool. It is a property of the request.

In January, a mandatory access control framework called SEAgent named the underlying pattern outright. It is the confused deputy, a problem the security literature described in 1988. A program holds real authority, and someone gets it to use that authority for something it was never granted for. Every agent you deploy with a service account and a tool list is a deputy, and the thing that makes it confused is that nothing in the request path knows which task the authority was for.

ActPlane goes further and argues that application-level guardrails are the wrong layer entirely, because an agent can reach past them through direct system calls, so enforcement belongs in the kernel via eBPF. Notably, that paper's unit of analysis is the agent harness, the same object I have been arguing is the real product surface.

A second line of work is about evidence rather than permission. The June 2026 survey From Agent Traces to Trust is the best available map of it, and its framing is sharp:

Final-answer accuracy alone cannot explain how an output was produced, which evidence supported each claim, whether tool calls were justified, how memory influenced later decisions, or where failures originated.

Their proposal is to treat an agent's execution as a typed graph, with evidence tracing as a projection of that graph onto what supported what. The stated goal is agent systems that are provenance-aware, auditable, and recoverable. That last word is doing quiet work. Recoverable is an operations property, and no log stream provides it.

The two lines are converging. A dual-graph paper from May 2026 aligns a provenance graph against an authorization graph, on the argument that neither works alone: provenance cannot stop an authorized party misusing data it may legitimately access, and authorization cannot detect a compromised party exploiting permissions it genuinely holds. You need both structures, and you need them aligned.

Meanwhile the ground truth is thin. A study of 10,008 GitHub repositories published in June went looking for declared permission boundaries and found them in 31 of 6,145 agent config files, against 8,158 of 24,436 GitHub Actions workflows in the same corpus. Half a percent versus a third.

Read that as indicative rather than measured, which is how the authors present it. Detection was regex-based, six of thirty-seven raw matches were false positives on manual check, and agent configs have no standard permission syntax to parse in the first place. Public repositories are also not enterprise deployments. The direction is still hard to argue with. We learned to write down what a build pipeline may touch. We have not started writing it down for the thing we hand a credential and a plan.

Where the standards actually stand

The Model Context Protocol shipped a new specification on 28 July, three weeks before I wrote this, and it is a serious piece of work: a stateless protocol core, a formal extensions framework, and real authorization hardening. Issuer validation per RFC 9207 to close an auth-server mix-up hole. Client credentials bound to the issuer that minted them. Dynamic client registration deprecated in favour of client ID metadata documents.

All of it client to server. Nothing in that release describes what happens when agent A asks agent B to call a tool on behalf of a person who authorized neither hop directly. The token proves a client may talk to a server. It does not carry who authorized the work, how far that authority extends, or how much of it has been spent.

Gartner named the same gap from the governance side. Their May forecast is that 40% of enterprises will demote or decommission autonomous agents by 2027 because of governance gaps found only after production incidents. The diagnosis in that release is more useful than the number. Enterprises treat agent governance as binary, locked down or fully trusted, and they fail to separate an agent's autonomy, meaning its ability to act, from its scope, meaning the breadth of what it can reach. Their data and analytics predictions point the same way: by 2030, half of agent deployment failures are expected to come from insufficient runtime enforcement.

Autonomy and scope are two different dials, and almost nobody is encoding either one in a form a machine can check at the moment of a call.

The market is starting to move. Okta's blueprint for the agentic enterprise, with its open XAA protocol and a reported twenty-five early adopters, is built around three questions: where are my agents, what can they connect to, what can they do. That is the right shape.

Disclosure: I am the author of AIP, an individual IETF draft and arXiv preprint, not a standard. It encodes delegation as a signed chain in which scope attenuates at every hop, so an agent can narrow the authority it passes on and can never widen it. Read that as one entry in a category that matters more than any entry in it.

How to build it

The target architecture has three planes, not one dashboard.

A decision plane that answers whether this call may proceed, carrying the subject, the scope, the delegation chain, and the budget remaining. It sits in the request path and it can say no. That is its entire value.

It also costs less than the objection assumes. A deterministic check, verify a signature and evaluate a policy, runs in single-digit milliseconds. The two to three hundred milliseconds people quote belongs to model-based content guardrails, which solve a different problem. Conflating the two is how the decision plane keeps getting deferred on a performance cost it does not actually carry.

If you want one concrete thing to hand your team, it is the shape of that call:

authorize(subject, agent, tool, arguments, delegation_chain, budget)
    -> allow | deny, policy_id, reason

An observation plane, which is what you already own. Spans, tokens, cost, evaluation scores. Keep it. Stop expecting it to prevent anything.

An evidence plane that holds execution provenance as a structure rather than a stream, so you can reconstruct what supported a claim, attribute an outcome to a decision, and recover from a bad one. This is still research. It is also the plane a regulator will eventually ask you for, and a log stream will not answer.

The useful test is whether your audit log records decisions or events. An event log says a tool was called. A decision log carries the fields from that signature: who the subject was, which policy applied, what the verdict was, what budget remained, and what would have flipped it to a denial. The second one is a control. The first one is a memory.

Four questions worth asking this week

Where is the slot? Ask your team to point at the exact place in the request path where a tool call could be denied. If the answer is a filter on prompt text or a dashboard alert, the slot is empty.

What is the subject? When your agent calls an internal system, whose identity is on the request. If the answer is a shared service account, you have no delegation model, and every question about who authorized what ends in the same place.

Can authority narrow? When one agent hands work to another, can the second do more than the first could. If nothing enforces attenuation, your blast radius is the union of every permission in the chain.

Does the log record a decision or an event? Pull one entry and read it. You will know within a sentence.

None of these require a platform purchase, and none of them are answered by better tracing. They are questions about where control sits. Right now, for most organisations, it sits after the fact, and the industry has spent the two years since that first taxonomy getting very good at describing exactly what it failed to stop.