The next agent failure will not always begin when the model makes a bad decision.
It may begin earlier, when someone gives the agent a capability nobody has really inspected. A tool connector. An MCP server. A portable skill. A local automation script. A browser action. A file-system permission. A workflow recipe copied from a vendor repo because it looked useful and came from a name people recognized.
That is the quiet change in the agent market right now. Agents are no longer just prompts wrapped around a model. They are becoming workers that load capabilities from many places, then use those capabilities to act inside real systems. The model still matters, but the operating risk is moving upstream. Before the agent acts, the business has already made a decision about what the agent is allowed to become.
NVIDIA’s May 19 post on verified agent skills makes that shift unusually clear. Their language treats skills as deployable agent capabilities, not as harmless text files. The skills are cataloged, scanned for software and agent-native risks, signed, and documented with machine-readable skill cards. The important sentence is not about convenience. It is about provenance: trust should come from “verifiable integrity and authenticity, not from implied provenance alone.”
That line is the market button.
A known name is not the same as a verified capability. A popular repo is not the same as a safe action path. A clean demo is not the same as a governed worker. If the agent is going to use a capability to touch customer data, trigger workflows, write code, send messages, change records, or coordinate with other agents, the business needs a ledger before it needs more autonomy.
The capability layer is now part of the operating system
Most teams still describe agent control at runtime. What can the agent do? What guardrails are active? What logs are kept? Who approves risky actions? Those are necessary questions, but they are not early enough.
A runtime policy can stop a bad action. It cannot fully compensate for a capability the organization never understood. If a skill’s declared purpose is narrower than its actual behavior, if a connector requests broader access than the work requires, if a tool description drifts, or if a workflow recipe carries hidden instructions, the agent’s action boundary has already been shaped by something upstream.
NVIDIA’s verified-skills process names several of those upstream risks directly: hidden instructions, prompt injection, trigger abuse, excessive agency, tool poisoning, and mismatches between a skill’s declared purpose, requested access, and bundled behavior. That list matters because it changes how operators should think. A skill is not merely instruction. It is a capability package that can alter what the agent tries, what it reaches for, and what it believes it is allowed to do.
Microsoft’s public Agent Governance Toolkit points at the other side of the same architecture. Its README frames runtime governance as evaluating every tool call, resource access, and inter-agent message against policy before execution. That is the right runtime posture. Policy belongs outside the prompt, at the action boundary, where it can allow, deny, log, and fail closed.
Put those two movements together and the pattern is obvious. NVIDIA is making the capability supply chain visible. Microsoft is making the execution boundary explicit. The practical operator should connect them.
The question is not only, “Did the agent follow the rules?”
The better question is, “Which verified capability entered the workflow, what authority did it carry, and which policy checked it before action?”
Implied trust is how demos become liabilities
Implied trust is comfortable during a pilot. The team knows the vendor. The repo has stars. The tool worked yesterday. The connector came from a platform everyone already uses. The agent ran in a test account. Nobody wants to slow down the excitement by asking for a chain of custody.
Then the pilot becomes useful.
A useful pilot gets copied into another workflow. Someone adds a new tool. Someone broadens permissions because the agent kept getting blocked. Someone pastes a skill from one coding agent into another environment. Someone connects the workflow to live data. The agent now has more reach than the original operating assumptions, but the business still thinks of it as the same experiment.
That is how implied trust turns into operational debt.
The public skepticism around production agents is already pointing here. In one indexed Reddit discussion, an operator said their company shut down or scaled back most internal agents after a productivity analysis showed they were “not actually saving us time,” because everything they produced had to be extensively reviewed and often redone by a human. That complaint sounds like a model-quality issue, but it is usually broader. The human is not only reviewing output. The human is compensating for unclear authority, unstable inputs, weak acceptance criteria, and capabilities nobody fully trusts.
When trust is not designed into the capability layer, it gets moved onto the reviewer.
That is expensive. It also defeats the whole promise of agents that actually work. The point is not to replace judgment with blind automation. The point is to reduce human load by making the agent’s work bounded, inspectable, and worth reviewing. A human review gate should decide edge cases, not re-perform the agent’s whole job because nobody trusts the path that produced the result.
The ledger is the missing artifact
An agent capability ledger is a simple operating record for every capability an agent is allowed to load or use.
It does not need to be fancy. It needs to be explicit. For each capability, the ledger should answer eight questions.
- Source. Where did this capability come from, and who maintains it?
- Declared purpose. What job does it claim to help the agent perform?
- Actual authority. What systems, files, tools, credentials, or data can it reach?
- Allowed actions. What may it read, draft, change, send, delete, approve, or trigger?
- Verification. Was it reviewed, scanned, signed, tested, or otherwise validated before use?
- Policy boundary. Which runtime rules evaluate its tool calls and resource access before execution?
- Evidence trail. What logs or artifacts show what happened when it was used?
- Stop condition. What forces the agent to pause instead of improvising?
That ledger turns a vague bundle of agent powers into a managed operating surface. It gives the business a way to inspect capabilities before they disappear into the agent’s reasoning loop. It gives security a concrete object to approve or reject. It gives operators a way to explain why an agent can handle one workflow but not another. It gives reviewers a reason to trust the path, not just the output.
For a small business, the ledger might be a table in Notion or Airtable. For a regulated enterprise, it may connect to identity, policy engines, audit logs, signed skill registries, and change management. The scale changes. The core artifact does not.
The ledger exists so nobody has to guess what the agent is made of.
Capability governance is not bureaucracy
The lazy objection is that all of this slows the work down. That is true only if the goal is to produce a demo.
For real operations, capability governance is speed infrastructure. It lets the team reuse approved capabilities without renegotiating trust every time. It lets a founder know which agent can touch sales data and which one cannot. It lets a technical manager swap models without accidentally changing the agent’s authority. It lets a consultant explain the difference between a safe workflow draft and a reckless production actor.
NVIDIA and ServiceNow used plain operational language around Project Arc: enterprises must define what an agent can see, which tools it can use, and how each action is contained. That sentence is not abstract governance. It is the everyday shape of a working agent.
What can it see?
What can it use?
How is action contained?
If those answers are not written down, they are living in someone’s assumptions. Assumptions do not scale. They also do not survive handoff, growth, tool changes, or the first serious incident.
The capability ledger makes the assumption inspectable before it becomes a failure.
The practical sequence
Before adding the next agent capability, run the ledger pass.
Start with one workflow, not the whole company. List the capabilities the agent already uses. Include obvious tools, hidden scripts, memory stores, APIs, MCP servers, browser permissions, file access, and human handoff mechanisms. Then mark which ones are verified, which ones are merely trusted by reputation, and which ones nobody has really inspected.
The first useful discovery is usually uncomfortable. A capability will have more access than its purpose requires. A tool will be allowed to write where it only needs to read. A human review gate will exist in conversation but not in the system. A vendor connector will be trusted because of the logo, not because anyone checked its actual behavior.
Good. That is the point.
Do not turn the discovery into a committee. Tighten the boundary. Reduce access. Add the stop condition. Move policy outside the prompt. Capture evidence. Decide whether the capability is approved, restricted, experimental, or blocked. Then let the agent work inside the cleaner lane.
That is how agent governance becomes operational instead of performative.
Bottom line
Agents are becoming easier to extend. That is useful. It is also dangerous if every new capability enters the workflow on vibes.
The business needs a chain of custody for what the agent can do before it judges what the agent did. Source, purpose, authority, verification, policy, evidence, and stop conditions are not paperwork. They are the operating substrate that keeps agent work trustworthy.
The model may be the brain. The capability layer is the hands. If you do not know where the hands came from, what they can touch, and who checked them before they moved, you do not have an agent that works.
You have an assumption with tools.
Sources
- NVIDIA Technical Blog, “NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents,” May 19, 2026, https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/
- Microsoft, “Agent Governance Toolkit” README, accessed May 23, 2026, https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/README.md
- NVIDIA Blog, “NVIDIA and ServiceNow Partner on New Autonomous AI Agents for Enterprises,” May 5, 2026, https://blogs.nvidia.com/blog/servicenow-autonomous-ai-agents-enterprises/
- Reddit indexed snippet, “anyone actually running AI agents in production for client work? or still demo-ware?”, accessed May 23, 2026, https://www.reddit.com/r/AI_Agents/comments/1tc7pxq/anyone_actually_running_ai_agents_in_production/
Stephen Nickerson.
Built for operators who need AI agents they can test, trust, and improve.