The agent market is starting to admit something important. Once an AI system can call tools, touch internal systems, and take action on someone’s behalf, model quality stops being the main operating question. The harder question is whether the company can see the action as it unfolds, attribute it to the right actor, and intervene before a bad step turns into a business event.

That is the layer now coming into view.

On June 17, WitnessAI introduced Agentic Control around the claim that enterprises need “greater visibility and control over their AI agents” because security teams often “lack the visibility to monitor or control their access.” The same day, Databricks positioned Unity AI Gateway around a similar expansion in scope, arguing that governance requirements now extend beyond models alone. Earlier in the month, Noma described the need in even more operational terms: organizations must be able to discover what is running, establish identity, and enforce policy automatically.

Those are not isolated product launches. They are evidence of a market correction. The industry spent the last wave talking about smarter models and more autonomous agents. The infrastructure layer is now moving to a more sober conclusion: delegated intelligence without runtime control is not automation maturity. It is blind delegation.

The problem is not agent risk in the abstract

A lot of teams still frame agent governance as some mix of prompt quality, model safety, and permissions hygiene. Those are real concerns, but they sit downstream of the actual operating failure. The deeper problem is simpler and less glamorous. Work has been delegated, but the chain of delegated action is not legible while it is still happening.

That distinction matters. A static permission tells you what an agent was allowed to access, not what it actually did with that access. A prompt log tells you what the model saw, not whether a tool call should have happened, whether retrieved context changed the task, or whether a later action drifted outside the original objective. A policy deck that says a human remains in the loop tells you almost nothing unless it also defines where that human enters, what evidence they see, what gets blocked automatically, and who owns the exception when the workflow stops behaving normally.

This is why the category is shifting from governance as paperwork to governance as runtime discipline. Once an agent starts acting, trust is no longer a matter of approved intent. It is a matter of observable sequence.

Identity matters, but sequence matters more

One of the more useful changes in recent agent infrastructure is the emphasis on distinct agent identity. Noma is right to push on that point. Shared credentials are a quiet disaster in an agentic environment because they destroy attribution at the exact moment attribution becomes essential. If several agents operate behind the same service account, the organization can see activity but not authorship. Something happened, but not clearly who initiated it, under what scope, or on whose authority.

Still, identity alone does not solve the control problem. An agent can be perfectly identifiable and still become dangerous during execution. The task can begin inside scope. The access can be legitimate. The tool can be officially approved. Then the session changes. A prompt injection, a retrieved document, a tool response, or an agent-to-agent handoff alters the work loop in the middle of execution. The permission remained valid; the behavior did not.

That is the mechanism these announcements are converging on. Noma states it directly when it warns that runtime inputs can redirect an agent into misusing authorization it was properly granted. Databricks reaches the same conclusion from the platform side when it expands governance to runtime interactions among models, agents, MCP servers, skills, and tools. WitnessAI reaches it from the security side when it argues that legacy controls were not built to inspect MCP traffic, tool invocations, or agent-to-agent workflows.

The shared thesis is clear. Knowing the actor is necessary. It is not sufficient. You also need to know whether the sequence of actions remained inside the task boundary.

Why old IAM logic breaks down here

Many organizations are about to make a familiar mistake. They will take identity and access management patterns built for human users, apply them to agents, and assume the control problem is mostly handled. That move will help, but it will not answer the harder question.

Traditional IAM works best when the actor follows a relatively visible path through a known application surface. An agent does something different. It composes prompts, retrieval, tools, structured outputs, and downstream actions into a fluid sequence that may change based on what happens mid-run. In that environment, the controlling question is no longer only whether access was granted. The controlling question is whether the evolving action chain still matches the task that was meant to be authorized.

That is why tool-level control is becoming such an important concept. A single MCP server can expose low-risk read operations beside high-impact write operations. A single integration can include safe lookup paths beside actions that alter records, send messages, trigger workflows, or move money. Broad approval is too coarse. Broad denial is too blunt. The operating answer is narrower and more architectural: which tools are exposed, to which class of agent, under which user or team context, with what logging, under what runtime checks, and with what intervention path when the pattern stops looking normal.

The more capable the agent becomes, the less useful coarse approval becomes. That is not a political statement about AI risk. It is a design statement about delegated systems.

This is just management discipline under new conditions

Strip away the AI branding and the pattern is ordinary. Companies have always known that authorization is not supervision. Giving someone a title, a system login, and a written procedure does not remove the need for review paths, audit trails, exception handling, and intervention when conditions change. Competent management never relies on role definition alone. It cares about whether the sequence of actions made sense in context.

Agents force that old truth into a new substrate. The capability itself is no longer the scarce thing. The scarce thing is the ability to place authority close enough to the work that control remains useful instead of ceremonial. That is why the current vocabulary matters: visibility, identity, approved tools, runtime enforcement, audit trail. These are not decorative enterprise features. They are the minimum control points required to keep delegated work legible.

Once you see that, the current market movement becomes easier to interpret. The real platform race is not only about producing better outputs. It is about building the supervision layer that makes outputs safe to operationalize.

The operating protocol that follows

If I were advising a founder, operator, or professional-services leader on where to start, I would not begin with model selection. I would begin with a runtime control protocol.

First, inventory the agents that already exist in the business. Not the ones in a strategy memo. The ones actually touching work today across chat tools, IDEs, workflow systems, browser automations, and internal software. Most organizations already have more agentic behavior in motion than their governance language acknowledges.

Second, assign attributable identity. Every agent should be nameable, ownable, and traceable to a clear authority boundary. If actions disappear into shared credentials, governance collapses into fog.

Third, define authority at the tool layer. Platform access is too broad a frame. The practical unit is the tool call and the action family behind it: read, write, trigger, modify, send, approve, escalate. Some should run automatically. Some should require review. Some should never be delegated.

Fourth, inspect the runtime chain as a single behavioral sequence. That means prompts, retrieved context, tool invocations, returned data, model outputs, and downstream actions all need to be visible together. A safe first step does not guarantee a safe fourth step.

Fifth, decide the intervention point before you need it. What gets blocked automatically? What gets paused for review? What evidence accompanies that review? Who owns the exception queue? When the same exception appears repeatedly, what gets redesigned in the workflow rather than tolerated indefinitely?

That sequence is not bureaucracy. It is the minimum viable substrate for agents that are supposed to do real work inside a real business.

What this means commercially

This shift also changes how the market should be interpreted by buyers and by anyone selling AI transformation. If your pitch still treats smarter models as the center of the story, you will increasingly sound behind the moment. The more serious buyer is already asking a different set of questions: what can the agent touch, how is authority scoped, where can someone inspect the run, what happens when the task drifts, and can the chain be reconstructed after the fact.

That is not fear. It is operational adulthood.

The better positioning is controlled delegation. Move one workflow into agentic execution without losing ownership of the tool boundary, the review route, the exception path, or the evidence trail. That is a much stronger promise than generic AI adoption language because it speaks to the actual decision operators are making. They are not buying intelligence in the abstract. They are deciding whether a delegated worker can be trusted inside production conditions.

Bottom line

The current agent market is standardizing around a harder and more useful truth.

Runtime control comes before trust.

Models still matter. Identity still matters. Permissions still matter. But once agents can act, the decisive governance layer moves closer to the action than most organizations are used to. The winners in this next phase will not be the ones with the loudest autonomy story. They will be the teams that can inventory the agent, attribute the action, narrow the tool boundary, inspect the sequence, and intervene before a bad step escapes into the business.

That is not anti-agent. It is the operating condition for agents that are ready to be treated like real workers.

Sources

  • WitnessAI, “WitnessAI Introduces Agentic Control to Secure and Govern AI Agents and MCP Servers,” published June 17, 2026. https://witness.ai/resources/witnessai-introduces-agentic-control-to-secure-and-govern-ai-agents-and-mcp-servers/
  • Databricks, “Building an open ecosystem for AI governance with Unity AI Gateway,” published June 17, 2026. https://www.databricks.com/blog/building-open-ecosystem-ai-governance-unity-ai-gateway
  • Noma Security, “Noma Launches Agentic Access Control to Govern AI Agents and MCP Servers Across the Enterprise,” published June 2, 2026. https://noma.security/blog/noma-launches-agentic-access-control-to-govern-ai-agents-and-mcp-servers-across-the-enterprise/

Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.