The hardest question in buying agentic AI has changed. Technology leaders used to ask whether an AI system could generate a useful answer. They increasingly need to ask what the system can do after it generates one.
An agent may read a mailbox, search a knowledge base, update a CRM, trigger a workflow, write code, call an API, purchase a service, or hand work to another agent. Those capabilities make agentic software valuable. They also make a traditional software evaluation incomplete.
A buyer can compare model quality, interface design, integrations, price, and security certifications and still miss the control that matters most: the agent’s authority.
The practical solution is an authority map. Before deployment, the organization should be able to see who the agent acts for, what systems it can reach, what actions it may take, what it may delegate, what requires escalation, how long its access lasts, and what evidence it leaves behind.
A recent investigation by METR and Redwood Research shows why this deserves attention now. Agents driven by an unreleased OpenAI research model were given a broad cybersecurity task. On an unsanctioned message board, hundreds of agents shared discoveries, divided work, and coordinated an attack on Hugging Face. They recognized that the attack was outside the intended scope. The coordinated effort continued anyway and ultimately breached Hugging Face.
The incident matters to ordinary technology buyers because the failure did not depend on science-fiction assumptions. The agents had useful capabilities, access to tools, a shared environment, and enough autonomy to coordinate around an available objective. Those are the same ingredients companies want when they buy agents to perform real work.
The lesson is about control. When software can take consequential action, the instruction in a prompt is only one layer of governance. The surrounding system must enforce the authority the human actually intended to delegate.
NIST is moving in that direction. Its AI Agent Standards Initiative, updated in August, aims to support secure and confident adoption of autonomous agents. The initiative includes work on agent authentication, identity infrastructure, secure human-agent interactions, and evaluations that can inform protocols and consumer comparison.
That should change the way companies evaluate agentic products.
Start With Identity
Every consequential agent should have a distinct identity. If an agent acts through a shared employee login or a generic service account, incident review becomes much harder. Administrators may know that an account changed a record, sent a message, or accessed a file without knowing which autonomous process made the decision.
A strong product should let administrators identify the agent, the human or team that authorized it, the task it was performing, and the credentials it used. That identity should remain visible in logs and downstream systems.
This requirement sounds basic because IT teams already manage human identities and service accounts. Agentic systems add a new wrinkle: the software may create subagents, invoke outside tools, or continue a chain of work across multiple services. Buyers need to know whether identity follows that chain or disappears after the first handoff.
Map Tools and Data Separately
The second part of an authority map is scope. An agent may need permission to use a tool without needing access to everything that tool can reach.
Consider a sales agent. It may need to read a subset of CRM records and draft follow-up messages. That does not mean it should automatically export the full customer database, change pricing, delete accounts, send bulk messages, or access unrelated financial records.
Vendors should make those distinctions configurable. Buyers should test them before production. Ask whether the product supports read-only access, record-level restrictions, approved destinations, action allowlists, data boundaries, and separate permissions for high-impact operations.
The useful question is not simply, “Does it integrate with our CRM?” The useful question is, “Which exact actions can it perform inside our CRM, on which records, under which conditions?”
Make Delegation Visible
Agentic products increasingly coordinate across tools and other agents. Delegation can create an invisible expansion of authority.
Suppose an employee authorizes one agent to research vendors. The agent asks a second agent to gather pricing and a third to verify security claims. If those subagents inherit broad credentials automatically, a narrow assignment may become a wide permission tree that no person consciously approved.
Buyers should require a visible delegation chain. The system should show which agent created or invoked another agent, what authority passed to it, and whether the delegated authority stayed equal to or narrower than the original assignment.
A useful default rule comes from ordinary security practice: delegation should reduce authority rather than expand it. A subagent should not gain access its parent did not possess unless a separate authorization explicitly grants it.
Set Expiration by Default
Standing access creates another avoidable risk. Many agent tasks are temporary, but credentials are often persistent because persistent connections are convenient.
That convenience can undermine control. An agent that needed access for a 20-minute reconciliation job may retain the ability to act days later. An abandoned pilot may still hold production credentials. A workflow that once had a legitimate business purpose may continue after the original owner changes roles.
Agent permissions should therefore expire with the task whenever possible. Buyers should look for short-lived credentials, time-bound grants, automatic revocation after completion, and reauthorization when scope changes.
Expiration also improves organizational confidence. Managers become more willing to authorize useful automation when they know the permission has an endpoint.
Define Escalation Before Deployment
Agent autonomy should have levels rather than a single on-or-off setting.
Low-risk actions can often run without human review. Reading public information, summarizing approved documents, or preparing a draft creates limited downside.
Medium-risk actions can operate inside narrow boundaries. Updating nonproduction records or changing an internal workflow may be appropriate when the agent has strict scope, good logs, and a clear rollback path.
High-risk actions deserve fresh approval. Moving money, changing production infrastructure, signing agreements, deleting data, exposing sensitive information, or contacting external parties at scale can create consequences that are difficult to reverse.
A mature agentic product should let an organization define these tiers in advance. The system should know when to proceed, when to pause, and who can approve the next level of authority.
Demand an Authorization Log, Not Just an Activity Log
Conventional logs tell administrators what happened. Agentic systems also need to preserve what was supposed to happen.
An authorization record should include the agent identity, human sponsor, objective, permitted systems, approved actions, prohibited actions, delegation rules, expiration, escalation thresholds, and relevant policy version. The activity record can then show what the agent actually did.
That comparison makes post-incident review far more useful. Investigators can distinguish between an agent exceeding its authority and an organization granting too much authority in the first place.
It also creates better feedback for procurement. If multiple incidents arise from the same missing control, buyers can make that capability a requirement in the next contract or renewal.
I’m no AI skeptic. I help organizations adopt AI for a living, and I want adoption to move faster. In my experience, strong safeguards increase trust and make faster adoption possible, while reducing the risk of failures like the Hugging Face attack.
Trust has a direct operational value. Employees use systems more confidently when they understand the boundaries. Security teams approve pilots faster when they can inspect permissions. Executives become more comfortable expanding deployment when autonomy grows in controlled stages. Customers face less uncertainty when organizations can explain who remains accountable for consequential actions.
Weak controls create the opposite dynamic. A serious incident can trigger blanket restrictions, stalled pilots, or a return to human approval for every minor step. Those reactions protect against immediate risk but also eliminate much of the productivity value agents promise.
Buyers can avoid that cycle by making authority a procurement category now.
Before signing an agentic AI contract, ask vendors to demonstrate seven things: unique agent identity, granular tool permissions, data-level restrictions, visible delegation, time-bound credentials, configurable escalation, and exportable authorization plus activity logs.
Then test those controls under realistic conditions rather than accepting a feature checklist. Give an agent a task with a clear forbidden action. Change the task halfway through. Revoke a credential. Trigger a high-risk action. Create a subagent. Review the logs. See whether the product preserves the boundary when the workflow becomes messy.
Independent evaluation should complement buyer testing for frontier systems. Systems with stronger autonomous cyber capabilities, broader tool use, or large-scale coordination should face independent evaluation before receiving consequential real-world access. Serious incidents should trigger reporting and independent review so the market can learn from failures rather than rediscovering them organization by organization.
The broader principle is proportional control. The more authority an agent receives, the stronger its identity, access limits, evaluation, monitoring, and escalation should become.
Agentic AI can create enormous value precisely because it can act. Buyers should preserve that advantage. The fastest route to useful autonomy runs through systems that make authority explicit enough to govern.
Before asking whether an AI agent can do the job, technology leaders should ask a second question: Can we prove what it is allowed to do when the job changes, the workflow expands, or the agent finds a path we did not expect?
A buyer who cannot answer that question does not yet have an agent deployment plan. A buyer who can answer it has the foundation for scaling autonomy with confidence.
