When Is an AI Agent Ready to Enter the Workplace?
An AI agent should not enter the workplace simply because it can complete a task.
It should enter when the organization can define what it may do, enforce what it must not do, intervene before consequential actions occur and reconstruct what happened afterwards.
That distinction matters because an agent is not merely a conversational form of software. Connected to email, customer records, internal documents or financial systems, it can retrieve information, select tools and initiate actions across organizational boundaries. Its value comes from this ability to act. So does its risk.
The market is moving faster than many organizations’ control environments. Gartner predicts that agentic AI will appear in 33% of enterprise software applications by 2028. Yet it also expects more than 40% of agentic AI projects to be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls.
For business leaders, model capability is only the starting point. The harder question is whether the organisation has established the conditions under which the agent can be trusted to act.
Readiness is a system property
Model benchmarks commonly measure whether an AI system can reason, answer questions or complete a sequence of tasks. These measurements are useful, but they are not deployment decisions.
An agent that performs well in a controlled evaluation may still be unsafe in the workplace if it:
- has excessive access to data or tools;
- acts under credentials broader than the user’s authority;
- treats untrusted content as instructions;
- executes irreversible actions without approval;
- cannot identify which policy governed a decision; or
- leaves no reliable evidence for investigation or audit.
The World Economic Forum’s AI Agents in Action report argues that the appropriate level of evaluation and human oversight should reflect an agent’s autonomy, authority and operational context.
This gives enterprises a better unit of analysis. The same model may be acceptable for summarizing a public report, conditionally acceptable for drafting a customer email, and unacceptable for sending that email or changing a customer record without additional controls.
Readiness must therefore be assessed at the level of a specific agent, performing a defined task, with particular permissions, data and consequences.
Six tests of workplace readiness

1. Is the agent’s job bounded?
A production agent needs a defined operating envelope:
- What objective may it pursue?
- Which systems may it access?
- Which records and fields may it read?
- Which actions may it execute?
- On whose behalf is it acting?
- Under what conditions must it stop?
“Help the sales team” is not an adequate boundary. “Search approved CRM tables and prepare a customer briefing, without changing records or contacting the customer” is much closer.
This is both a governance requirement and a business discipline. If the task cannot be specified, its value, risk and performance cannot be measured consistently.
2. Is authority enforced outside the prompt?
A prompt telling an agent to “access only authorized information” is an instruction, not an access-control mechanism.
Agent permissions should be constrained at the execution layer through measures such as:
- per-agent tool allowlists;
- role- and user-based authorization;
- structured query interfaces rather than unrestricted SQL;
- server-side validation of tables, fields, operators and record identifiers;
- scoped, short-lived credentials; and
- refusal of unknown tools or unsupported operations.
This matters because the model should not be the final authority on whether its own proposed action is permitted. Prompt injection, tool poisoning or reasoning errors can influence model behaviour. They should not be able to rewrite the organization’s security boundary.
OWASP’s Agentic AI – Threats and Mitigations describes emerging threats created by autonomous, tool-using systems and sets out a threat-model-based approach to mitigation. Its broader lesson is that effective agent security depends on controls across identity, permissions, tools, data flows and execution.
Research reinforces this point. AgentDojo tests agents on realistic tasks involving email, banking and travel tools while exposing them to malicious instructions embedded in the information they process. The benchmark shows that agents can struggle both to complete legitimate tasks and to resist attempts to redirect their behaviour.
AutoDojo subsequently tested defences against attacks adapted to the defence itself. In its experiments, AutoDojo’s adaptive attack achieved a 28% overall attack success rate against a filter that had reduced the success rate of static attacks to zero. This does not establish a universal failure rate, but it demonstrates why a defence should not be considered reliable solely because it performs well against a fixed test set.
A strong readiness test therefore asks whether prohibited actions remain technically unavailable even when the model is manipulated.
3. Is sensitive data protected before it reaches the model?
An agent may be authorized to use a customer record without being entitled to disclose every field in that record to a model provider.
Data minimization must operate at inference time. Relevant controls can include:
- selecting only the fields required for the task;
- masking or tokenizing personal information before model egress;
- restricting processing locations;
- separating reversible token vaults from model access;
- preventing sensitive values from appearing in logs; and
- failing safely when data classification is unknown.
The legal analysis remains use-case dependent. Under data-protection regimes such as the GDPR, an organization must still establish a lawful basis, limit personal data to what is necessary, apply appropriate security and demonstrate accountability. Calling a system an “agent” does not displace those obligations.
4. Are consequential actions held for meaningful human approval?
Human oversight is effective only when it changes the execution path.
For higher-impact actions, the agent should prepare a proposed action and pause before execution. The reviewer must be able to see:
- what will happen;
- which person, data or system will be affected;
- why the action was proposed;
- which policy triggered review; and
- whether the action can be rejected or modified.
The reviewer must also possess the authority, time and competence to intervene. An approval button shown after an action has occurred is not oversight. Nor is approval meaningful if reviewers routinely confirm opaque recommendations without understanding their consequences.
For high-risk AI systems, Article 14 of the EU AI Act reflects this functional approach. Human oversight measures must enable people to understand relevant capabilities and limitations, remain alert to automation bias, interpret outputs and disregard, override or interrupt the system.
Not every workplace agent will fall within the Act’s high-risk classification. The underlying principle provides a useful design test: oversight should give people meaningful operational control over the system.
5. Can the organization reconstruct every material action?
A workplace agent should leave an evidence trail that answers:
- Who requested the action?
- Which agent and model were involved?
- What tools and data sources were used?
- Which policy version applied?
- Was the action allowed, denied or held?
- Who approved it?
- What was executed?
- What changed as a result?
NIST’s AI Risk Management Framework treats governance, measurement and ongoing risk management as connected activities. For agents, that connection should be visible in runtime evidence.
Logs must also be designed carefully. Recording everything can create another privacy and security risk. Audit records should preserve decision-relevant facts while masking unnecessary sensitive content and protecting their integrity, retention and access.
6. Has the complete workflow earned its business case?
A technically controlled agent can still be unready if it solves no valuable problem.
Before deployment, organizations should establish:
- a baseline for the existing workflow;
- task-success and error rates;
- the cost of review and exception handling;
- latency and reliability targets;
- security and policy-violation thresholds;
- escalation and rollback procedures; and
- a measurable business outcome.
Evaluation must cover the full workflow—not only the model’s answer. That includes identity, retrieval, tool selection, authorisation, approval, execution and evidence generation.
Readiness should also expire. Material changes to the model, tools, permissions, data sources or policy environment should trigger reassessment.
From policy statements to runtime controls
ZeroH’s approach starts from a simple premise: governance must operate where the agent acts.
This approach is reflected in ZeroH’s architecture through structured CRM queries, tool and host allowlists, server-side validation, PII masking before model access, approval gates for write operations, versioned policy decisions and runtime audit records.
These mechanisms illustrate a wider architectural shift. A policy should not remain a sentence in a governance document. It should be translated into an enforceable decision at the point of action, with evidence showing whether the control operated as intended.
This does not make an agent infallible. No control system can eliminate every model, security, human or organizational failure. It does, however, make authority bounded, intervention possible and accountability testable.
The real admission decision
An AI agent is ready for the workplace when the organization can answer six questions with evidence:
- What exactly is it employed to do?
- What authority can it exercise?
- What data can it see and disclose?
- Which actions require human judgement?
- Can every material decision be reconstructed?
- Does the controlled workflow produce measurable value?
Capability gets an agent through the interview.
Governed authority is what should get it through the door.
Explore how ZeroH brings policy, runtime control and evidence together at zeroh.io.
References
- World Economic Forum, AI Agents in Action: Foundations for Evaluation and Governance
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
- OWASP, Agentic AI – Threats and Mitigations
- AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents
- How should we assess security and data minimisation in AI?
- AutoDojo: Adaptive Attacks Expose Superficial Defenses and User-Underspecification Limits in LLM Agents
- Regulation (EU) 2024/1689, particularly Article 14 on human oversight
- Gartner, “Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” 25 June 2025