The Enterprise AI Agent Readiness Test

Govern authority action by action – not by model, platform or use-case label

Altivate | Published 24 May 2026 | Updated 26 July 2026

1. The gap between an assistant and an agent is authority

Enterprises have spent the last two years testing systems that answer questions, summarise documents and draft content. The next category does something materially different: it selects steps and uses tools to pursue a goal.

That difference is often described as autonomy. For governance, authority is the more useful word. An assistant produces an output for a person to assess. An agent can acquire data, call an application, change a record, initiate a communication or ask another agent to continue the work. The moment it can act, the quality of its prose stops being the main risk.

This is why a model benchmark cannot approve an enterprise agent. The same model can be safe when it retrieves a policy, tolerable when it drafts a case response, and unacceptable when it closes the case or changes an entitlement. The model did not change. The available action did.

NIST’s 2026 AI Agent Standards Initiative centres three areas that reflect this change: interoperable protocols, identity and authentication infrastructure, and security evaluation. Its companion concept paper on software-agent identity and authority names the relevant enterprise surface directly: agents gain access to data, tools and applications, so organisations need ways to identify them, constrain what they may do, audit their activity and establish accountability. That paper is a concept paper, not a completed standard. Its value here is the problem definition.

The readiness test in this paper therefore does not ask whether an organisation has selected the best model. It asks whether the organisation can control the work around the model.

Context: Generative and agentic AI and the role of forward-deployed AI engineers in moving a bounded use case from prototype into an operating environment.

2. Start with an action inventory, not a use-case list

“Customer-service agent” is a programme label. It is not an access policy.

Break the proposed job into observable actions:

This decomposition prevents a familiar mistake: controls are attached to the use case as a whole, then inherited by every tool inside it. In practice, each action needs its own answer to five questions:

1. What exact data can it read?
2. What exact state can it change?
3. Under whose identity does it act?
4. What evidence must exist before execution?
5. What happens when the evidence, policy or tool is unavailable?

The safest first release is usually asymmetric. Give the agent the minimum purpose-bound read access needed for the action and an even narrower write surface; let it draft more than it sends; let it recommend more than it approves. This is not a maturity ladder where every action should eventually become autonomous. Some boundaries are the operating design.

3. The twelve-question readiness test

Score every proposed action, not the agent brand or the programme. “Yes” means evidence exists now, not that a project plan says it will.

Ownership and purpose

1. Is there one accountable business owner for this action? The platform team can own the runtime. It cannot own a pricing concession, a hiring decision or a maintenance shutdown. The owner must have authority over the process consequence.

2. Is the action’s intended outcome measurable without asking the model to grade itself? Useful measures are observable: correct case routing, accepted draft rate, policy-citation accuracy, avoided duplicate work, or time to human resolution. “Helpful” is not an acceptance criterion.

3. Is there a non-agent baseline? Without the existing error rate, cycle time and exception volume, a pilot can prove activity but not improvement. The comparison may be a person, a deterministic workflow or a simpler retrieval-and-draft system.

Authority and execution

4. Does the agent have a dedicated, scoped identity? A shared integration user destroys attribution. A human user’s delegated session can give the agent more authority than its job requires. The identity should be recognisable as non-human, short-lived where possible, and limited to named operations and resources.

5. Is authorisation checked when the action executes? Permission at design time is not enough. Roles, records and case state change. The execution service must decide whether this action is allowed now, on this object, in this context.

6. Is decision-making separated from execution? OWASP’s agent-security guidance recommends an independent execution layer that validates scope, privilege and approval state. The model may propose “refund order 123 by AED 400.” A deterministic component should validate the order, limit, policy evidence, duplicate status and approval before calling the payment system.

7. Does the system fail closed? Missing policy, expired identity, unavailable approval service, uncertain target or malformed tool response should stop the action. Replacing a failed check with the model’s best guess is not resilience.

Evidence and evaluation

8. Can a reviewer reconstruct why the action happened? Keep the relevant input, retrieved evidence, model and prompt version, proposed action, approval state, tool request, tool result and final state. Do not rely on a transcript alone; a transcript may not show what the downstream system actually committed.

9. Are evaluations built from the real exception distribution? A clean set of successful examples tests the happy path. Production evaluation needs policy conflicts, stale records, inaccessible sources, prompt injection, ambiguous identities, duplicated requests, partial tool failures and attempts to exceed authority. Anthropic’s evaluation guidance is useful vendor practice here: define tasks from observed failures and score the outcome with multiple signals rather than one model judgement.

10. Are security tests run across the whole action chain? NIST’s Generative AI Profile and OWASP both treat prompt injection and data leakage as system risks, not prompt-writing defects. Test untrusted documents, tool descriptions, memory, retrieval results and agent-to-agent messages. A model that refuses a malicious user prompt may still follow the same instruction when it arrives inside a PDF.

Intervention and recovery

11. Is the human checkpoint attached to the consequence? “Human in the loop” is meaningless if the human sees a generic confirmation after the action. For sensitive or irreversible steps, show the exact target, effect and supporting evidence at the point where approval can still stop execution. OpenAI’s agent-building guide makes the same practical distinction: intervene after repeated failure and before high-stakes or irreversible actions. It is vendor guidance, but the control is independently sensible.

12. Can the organisation stop, contain and reverse the action? Name the kill switch, the person authorised to use it, the maximum time to disable execution, the records needed to find affected transactions and the compensating action for each tool. “Roll back the model” does not reverse an email, payment or production command.

This is not a twelve-point additive score. Questions 4-7 and 12 are mandatory gates: scoped identity, execution-time authorisation, independent execution validation, fail-closed behaviour and tested containment or recovery. One “no” in those gates prevents delegated production action, however strong the remaining answers. A passing action is not risk-free; it is operable because the organisation knows who owns it, how it is constrained, how it is measured and how it stops.

4. A practical delegation ladder

Use the least authority that still produces the intended value:

This ladder is deliberately not called a maturity model. A public-service eligibility decision may remain at “recommend” permanently. A low-value duplicate-ticket closure may justifiably reach “execute within envelope.” The right end state follows the consequence, not the technology’s capability.

Two anti-patterns appear repeatedly.

Approval by category. A user approves “let the agent process refunds” and the system treats that as approval for any amount, customer and evidence state. Approval should bind to an exact action or to a formal envelope with limits that the execution service can enforce.

Autonomy by accumulation. A read-only pilot gains one write tool, then another, while the original risk assessment remains unchanged. Re-run the twelve questions whenever a tool, data source, model, memory mechanism or downstream agent expands the reachable consequence.

5. Protocol support is not business authorisation

Two protocol families are becoming relevant to enterprise agent programmes.

The Model Context Protocol (MCP) standardises how a model-facing application discovers and calls tools and resources. Its current HTTP authorisation specification uses OAuth 2.1 and protected-resource metadata. Authorisation is still optional at the protocol level. “Uses MCP” therefore does not mean “secure by default,” and successful authentication does not answer whether the business action is permitted.

The Agent2Agent (A2A) protocol standardises discovery and communication between independent agents. Version 1.0 treats agents as enterprise applications, requires authorisation on protocol operations and uses an Agent Card to publish identity, skills, endpoint and authentication requirements.

Both solve useful interoperability problems. Neither knows that this customer is in a dispute, this purchase exceeds a delegated limit, this case needs two approvers or this employee must be offered an appeal. Protocol identity answers who is calling. Business authorisation answers whether this caller may perform this action on this object now.

Keep those layers separate:

1. protocol authentication establishes the caller;
2. platform policy limits reachable tools and resources;
3. the business service validates the transaction and current authority;
4. the audit trail records the proposed and committed state.

If the model is the only layer deciding all four, the architecture has no independent control boundary.

6. The minimum production packet

Before an action moves beyond a supervised pilot, the approval pack should fit on a few pages and contain:

• the action inventory and delegation level;
• the named business owner and technical operator;
• the dedicated identity, permissions and credential lifetime;
• the source and tool allow-list;
• the deterministic checks performed before execution;
• the evaluation set, thresholds and unresolved failure classes;
• the human-approval design for consequential actions;
• the event and outcome fields retained for audit;
• the stop conditions, kill-switch owner and maximum disable time;
• the reversal or compensation method;
• the change triggers that force reassessment.

This packet is more useful than a generic “responsible AI” statement because it can be tested. Remove the identity and see whether execution fails. Send an expired approval and see whether it stops. Insert a hostile instruction in a retrieved document. Make the tool time out after partially committing. Ask the operator to find every action taken by a retired model version.

Readiness is demonstrated by those results, not by the presence of a governance committee.

Altivate’s own operating context matters here: the company is certified to ISO/IEC 27001 and ISO/IEC 42001. Those management systems can provide ownership, risk and change-control structures. They do not approve an action automatically. The twelve questions still need action- level evidence.

Altivate’s ISO/IEC 42001 certification announcement explains the management-system context.

7. The readiness test is a control gate, not legal clearance

The test does not choose a model, framework or cloud, and it does not make MCP or A2A mandatory. NIST’s software-agent identity work is a 2026 concept paper and standards initiative, not a completed normative standard; vendor implementation guidance is not proof of product safety.

A complete score still requires domain-specific legal and policy review for employment, credit, health, public service and other consequential uses. There is no single acceptable autonomy level. The consequence of the individual action determines the boundary. Protocol and standards status was checked 26 July 2026 and must be refreshed before revision.

8. The executive agenda

1. Take one proposed agent and list every external effect it can cause. Do not group them.
2. Run the twelve questions against each action and assign a delegation level.
3. Require a production packet before any write-capable release.
4. Test expired approval, hostile retrieved instructions, partial tool failure and model rollback.
5. Keep high-consequence actions behind exact human approval until evidence earns a narrower boundary.

The usual outcome is not “stop the programme.” It is a smaller first release: retrieval and drafting proceed; a few low-consequence actions execute inside hard limits; high-consequence actions retain exact human approval. That shape produces usable evidence without betting the control environment on a demo.

Altivate works across AI architecture, data, enterprise applications and operating controls in Saudi Arabia, the UAE, Jordan and India and is certified to ISO/IEC 27001 and ISO/IEC 42001. The management system provides the structure; the action-level evidence decides whether software may act.

Start with generative and agentic AI, or return to White Papers.

Sources and verification status

Checked 26 July 2026.

Standards and public guidance – [read]

• NIST, AI Agent Standards Initiative
• programme scope covering protocols, identity and authentication infrastructure, and evaluation. Created 17 February and updated 20 April 2026.
• NIST NCCoE, New Concept Paper on Identity and Authority of Software Agents
• identity, authorisation, auditing and non-repudiation problem statement. Concept paper, not final standard.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile – system-level risk and evaluation guidance.
• OWASP Cheat Sheet Series, AI Agent Security
• threat categories and independent execution-layer pattern. Community guidance, not a regulator.
• Model Context Protocol, authorisation specification dated 2025-11-25 – OAuth-based HTTP authorisation; optionality stated in the specification.
• A2A Project / Linux Foundation, protocol specification 1.0 – protocol authorisation and Agent Card requirements.

Vendor implementation guidance – [read, vendor guidance]

• OpenAI, A practical guide to building AI agents
• intervention thresholds and sensitive-action review.
• Anthropic, Building effective agents
• workflows versus agents and the simplest-sufficient-architecture principle.
• Anthropic, Demystifying evals for AI agents
• task construction and evaluation practice.