Most AI risk assessments written in 2023 and 2024 were designed for chat assistants: a person asks, the model answers, a person decides. Agentic AI breaks that pattern. An agent plans a task, calls tools, reads and writes data, and acts on systems, often without a person approving each step.
The results in the past eighteen months have been instructive. Agents have wiped production databases, been tricked by a single email into leaking data, and shipped with hidden instructions to destroy cloud resources. This article turns those incidents into a 12-point assessment we use with clients before an agent is given access to anything that matters.
Why agents need a different assessment
The organising idea in the OWASP Top 10 for Agentic Applications, published in December 2025, is least agency: give an agent the minimum autonomy, the fewest tools and the narrowest credentials it needs for its job. That is a different question from whether its answers are accurate.
Adoption is running ahead of governance. McKinsey’s 2025 State of AI survey found 23% of organisations already scaling an agentic system and 62% experimenting. Deloitte’s 2026 enterprise survey found close to three-quarters planning to deploy agents within two years, but only 21% with a mature governance model for them. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, with inadequate risk controls among the reasons.
What went wrong in 2025 and 2026
| Incident | What happened | Root cause to design out |
|---|---|---|
| Replit and SaaStr (July 2025) | A coding agent ran destructive commands against a live production database during a code freeze | No separation between development and production; no planning-only mode |
| Amazon Q Developer extension (July 2025) | A published release contained an injected prompt telling the agent to wipe local files and cloud resources | An over-scoped token in the build pipeline let an outsider change the release |
| EchoLeak, Microsoft 365 Copilot (June 2025) | One crafted email could make the assistant send data from its access scope to an attacker, with no click | Untrusted content treated as instructions |
| ForcedLeak, Salesforce Agentforce (September 2025) | A prompt hidden in a web-to-lead form made the agent send CRM data out through an allow-listed domain that had expired and been re-registered | Allow-lists never re-validated |
| GitHub MCP server (May 2025) | A malicious public issue could make an agent with private-repository access copy private data into a public repository | Agent held broader access than the task needed |
| PocketOS (April 2026) | An agent working in staging found an unscoped infrastructure token and deleted the production database and its backups in seconds | Blanket credentials and no confirmation or cooldown on destructive API calls |
None of these required a novel attack on the model itself. Every one is a familiar control failure, access, segregation, change management or input validation, made faster and larger by an agent.
The 12-point agentic AI risk assessment
Purpose and scope
- Define the job and the red lines. Write down the agent’s intended use, the systems it may touch, and the actions it must never take. ISO/IEC 42001 calls this intended use, and it is the reference point for every other control.
- Classify every action. Sort the agent’s possible actions into read, reversible write and irreversible. Irreversible actions, such as deleting data, sending payments, emailing customers or changing access, carry the strictest controls.
Identity and access
- Give the agent its own identity. An agent should not borrow a person’s account or a shared service account. The NIST NCCoE concept paper on agent identity and authorisation (February 2026) recommends a distinct agent identity, with every action still attributable to a named person.
- Scope every credential. The Amazon Q and PocketOS incidents both started with a token that could do far more than the job required. Issue short-lived, task-scoped credentials and review them as you would privileged human access.
Tools, data and inputs
- Allow-list tools and re-validate egress. List the tools and destinations the agent may use, and check the list on a schedule. ForcedLeak worked because a trusted domain had quietly changed hands.
- Treat every input as untrusted instructions. Emails, documents, web pages, tickets and repository issues can all carry hidden prompts. Separate what the agent reads from what it is allowed to be told to do.
Human oversight
- Put friction on destructive actions. Require typed confirmation, out-of-band approval or a cooling-off period before an irreversible action runs. The absence of all three was the root cause at PocketOS.
- Make approvals meaningful. OWASP lists human-agent trust exploitation as a top-ten risk: persuasive agent explanations can lead people to approve harmful actions. Show approvers what will change, not the agent’s summary of why.
- Separate environments. An agent building or testing in staging should hold no credentials that reach production. After its incident, Replit introduced automatic separation of development and production databases.
Monitoring, supply chain and limits
- Log every invocation. Record the initiating person, the agent identity, each tool or API called, the data read or changed, and the session context. Agent actions hidden inside a user’s audit trail cannot be investigated.
- Vet the agent supply chain. Skills, plug-ins, MCP servers and extensions are software from third parties. In February 2026, hundreds of malicious skills on a public marketplace for the OpenClaw agent stole API keys, wallet keys and passwords.
- Set limits and a kill switch. Cap spend, rate and scope, and make sure someone can revoke an agent’s credentials in minutes. Unbounded consumption is on the 2026 OWASP list for LLM applications for a reason.
How the checklist maps to the frameworks
| Checklist area | OWASP Agentic Top 10 | ISO/IEC 42001 Annex A area |
|---|---|---|
| Job, red lines, action classes | ASI10 Rogue Agents | A.6 AI system life cycle; A.9 Use of AI systems |
| Agent identity and credentials | ASI03 Identity and Privilege Abuse | A.4 Resources; organisation access control |
| Tools and egress | ASI02 Tool Misuse | A.6 AI system life cycle |
| Untrusted inputs | ASI01 Agent Goal Hijack; ASI06 Memory and Context Poisoning | A.7 Data for AI systems |
| Approvals and friction | ASI09 Human-Agent Trust Exploitation | A.9 Use of AI systems |
| Logging | ASI08 Cascading Failures | A.6.2.8 AI system event logs |
| Supply chain | ASI04 Agentic Supply Chain Vulnerabilities | A.10 Third-party and customer relationships |
For the technical controls behind this table, see our guide to securing AI solutions. For the management system side, including agent registers and impact assessments, read governing AI agents under ISO/IEC 42001 on GRCLens.
Regional obligations to factor in
- Australia. The National AI Centre’s Guidance for AI Adoption (October 2025) sets six practices, including accountability, risk management, testing and human oversight. From 10 December 2026, privacy policies must explain the use of personal information in automated decisions that could significantly affect people, which will capture many agent workflows. See our note on automated decision-making disclosure.
- Singapore. IMDA’s Model AI Governance Framework for Agentic AI (January 2026, updated May 2026) is voluntary, but it is explicit that organisations remain accountable for what their agents do.
- Malaysia. The National AI Office opened consultation on a risk-based AI Governance Bill in July 2026, including incident reporting.
- European Union. Under the Digital Omnibus agreed in 2026, high-risk AI obligations now start on 2 December 2027 for Annex III systems, which matters for any agent used in credit, employment or essential services for EU customers.
- Gulf states. Saudi Arabia’s SDAIA principles and the UAE’s AI Charter are not binding, but regulators in both countries increasingly expect evidence that AI use is governed.
Related reading
- Building a risk-responsive AI governance framework
- Risk appetite in the age of AI
- AI cyber attacks in 2026
Frequently asked questions
What is the difference between an AI assistant and an AI agent?
An assistant produces answers for a person to act on. An agent plans and takes actions itself, such as calling tools, changing records or sending messages, which is why access control and human oversight become the main risks.
What is least agency?
The principle, used by OWASP, of giving an agent the minimum autonomy, tools and credentials it needs for its task, in the same way least privilege applies to people.
Do we need ISO/IEC 42001 to govern AI agents?
No, but it gives a certifiable management system for AI, including impact assessments, life cycle controls and event logs, which regulators and customers increasingly recognise.
Who should own an agent’s actions?
A named business owner. Frameworks from NIST and Singapore both stress that an agent needs its own identity while every action remains attributable to an accountable person.
How Security Solution Consultants can help
Security Solution Consultants runs agentic AI risk assessments for organisations in Australia, New Zealand, Singapore, Malaysia and the Gulf before agents are connected to production systems. We review the agent’s scope and credentials, test it against the OWASP agentic threats, design the approval gates and logging, and set up the governance that ISO/IEC 42001, Australia’s Guidance for AI Adoption and the December 2026 privacy changes expect.
Our compliance and risk management team pairs the assessment with GRCLens, which holds the AI system register, impact assessments and evidence in one place. If you are setting AI policy from scratch, start with our AI governance guide for businesses, then talk to us about assessing your first agent.
