AI Security
Prompt Injection
AI Agents
Prompt Injection Is an Access-Control Problem: How ISO 27001 Auditors Should Test AI Workflows
A practical guide to auditing prompt injection, AI agents, permissions, connected tools, authorization boundaries, logging, human approvals, and AI workflow security under ISO 27001.
Prompt Injection Is More Than an AI Input Problem
Prompt injection is often treated as an AI input-filtering problem.
That view is too narrow.
If an AI assistant can only summarize public documents, a malicious instruction may simply produce a bad answer.
However, if the same AI assistant can access email, SharePoint, customer records, source code, cloud systems, databases, or administrative tools, the risk changes completely.
The first question is:
“Can someone manipulate the model?”
For an ISO 27001 internal audit, there is an even more important question:
“What is the manipulated model allowed to access or do?”
For ISO 27001 internal auditors, this makes prompt injection an access-control, authorization, logging, application-security, and risk-management issue.
Quick Answer
How Should ISO 27001 Auditors Test Prompt Injection Risk?
ISO 27001 auditors should test what happens when an AI workflow receives malicious or untrusted instructions.
The audit should determine whether the AI can access data, call tools, perform actions, modify records, send information, or use privileges beyond what the business process requires.
Auditors should review the AI identity, user permissions, connected systems, tool permissions, data boundaries, approval steps, logs, monitoring, vendor controls, and incident response processes.
Bottom line: do not only test whether the AI follows a malicious prompt. Test whether a compromised AI workflow can cross an authorization boundary.
Why Prompt Injection Matters in 2026
AI systems are moving beyond simple chat.
Organizations now use AI to read emails, search files, summarize support tickets, review code, create records, query databases, generate reports, and trigger business workflows.
That makes prompt injection more serious.
OWASP identifies prompt injection as a major LLM application risk. It also highlights excessive agency, where AI systems receive too much functionality, permission, or autonomy.
NIST has also increased its focus on AI agent identity and authorization. In 2026, NIST highlighted identification, authorization, auditing, non-repudiation, and controls for prompt injection when discussing software and AI agents.
Recent Microsoft security guidance reaches a similar conclusion. AI agents should have dedicated identities, tightly scoped permissions, controlled tools, and end-to-end auditability rather than relying on prompts to define what an agent should or should not do.
Practical rule: ISO 27001 auditors should treat prompt injection as a control-effectiveness test, not only an AI security test.
Need Help Auditing AI Workflows?
Canadian Cyber helps organizations test AI workflows as part of ISO 27001 internal audits, AI governance reviews, and ISO 42001 readiness.
We can review AI access, connected systems, permissions, tool use, evidence, vendor risk, logging, human approvals, incidents, and corrective actions.
ISO 27001 AI Workflow Audit: Quick Snapshot
| Audit Area | What the Auditor Should Test |
|---|---|
| AI Identity | Does the AI workflow use a defined and controlled identity? |
| Access Rights | Can it access more information than the workflow requires? |
| Tool Permissions | Can it call unnecessary tools or functions? |
| Write Access | Can it modify, delete, send, approve, or publish information? |
| User Context | Does the AI inherit the correct user’s permissions? |
| Human Approval | Are high-impact actions independently approved? |
| Prompt Injection | Can untrusted content alter the AI’s behaviour? |
| Data Boundaries | Can the AI retrieve information outside the intended scope? |
| Logging | Are prompts, tool calls, authorization decisions, and actions recorded? |
| Monitoring | Can unusual AI behaviour be detected? |
| Incident Response | Can AI access be quickly disabled after an incident? |
| Evidence | Can the organization prove these controls operate? |
The Wrong Way to Audit Prompt Injection
A weak audit may ask the development team:
Auditor:
“Do you protect against prompt injection?”
Development Team:
“Yes. We have system prompts and guardrails.”
The auditor records the answer and moves on.
That is not enough.
System prompts can influence model behaviour. However, they should not become the primary authorization mechanism.
Prompt Instruction
“Never reveal confidential files.”
Stronger Security Boundary
Prevent the AI identity from retrieving confidential files in the first place.
Prompt Instruction
“Never send an email without permission.”
Stronger Security Boundary
Remove the send capability or require independent approval before transmission.
Practical rule: security should not depend entirely on the model remembering its instructions. Authorization should exist outside the model.
Prompt Injection Becomes Dangerous When AI Has Authority
Consider an AI assistant that summarizes incoming emails.
The workflow requires read-only access.
However, imagine that the same integration also allows the AI to:
An attacker sends an email containing hidden or persuasive instructions.
The AI reads it.
The malicious instruction tells the AI to search the mailbox for sensitive information and send that information elsewhere.
The prompt injection created the trigger.
The excessive permissions created the impact.
OWASP uses this type of scenario when explaining excessive agency and recommends minimizing tool functionality, permissions, autonomy, and unnecessary extensions. That distinction should shape the internal audit.
The Auditor’s Main Question
“If the model becomes confused, manipulated, compromised, or simply wrong, what can it actually do?”
That question changes the audit. Instead of focusing only on prompt wording, auditors begin testing authority.
- What systems can the workflow reach?
- What information can it retrieve?
- What tools can it call?
- Can it write or delete information?
- Can it send information externally?
- Can it approve transactions?
- Can it change permissions?
- Can it create accounts?
- Can it trigger another automated workflow?
- Can it perform these actions without a human decision?
The answers reveal the real exposure.
1. Identify Every AI Workflow
You cannot audit AI access if you do not know where AI operates.
Start with an AI system and workflow inventory.
Do not limit the inventory to ChatGPT, Copilot, Gemini, Claude, or other obvious AI platforms.
AI capabilities may exist inside CRM systems, ticketing platforms, Microsoft 365, development tools, security platforms, meeting assistants, customer support tools, browser extensions, and SaaS applications.
Document for Every AI Workflow
- Business purpose
- Business owner
- AI service
- Data sources
- Connected systems
- Available tools
- Permissions
- Authentication method
- User population
- Approval requirements
This inventory becomes the starting point for risk assessment and audit sampling.
2. Test the AI Identity
Traditional systems ask:
Who is the user?
AI workflows add another question:
Under whose authority is the AI acting?
An auditor should determine whether the AI uses a dedicated identity, shared service account, API key, delegated user identity, application identity, or another authentication method.
Shared, highly privileged identities should receive additional scrutiny.
A dedicated identity improves accountability.
It also makes access review, revocation, monitoring, and investigation easier.
3. Test Least Privilege
Compare actual permissions against the approved business purpose.
Example: Support Ticket AI
Suppose an AI assistant only needs to summarize support tickets.
- Why can it delete tickets?
- Why can it export customer records?
- Why can it change ticket ownership?
- Why can it view every customer’s account?
- Why can it access administrator functions?
These are access-control questions.
AI identities should receive only the permissions required to perform approved tasks.
Read-only workflows should normally use read-only permissions.
A workflow operating for one department should not inherit organization-wide access without a justified reason.
4. Test Tool and Function Access
Modern AI agents may connect to tools that allow them to search, write, send, execute, publish, modify, or delete.
The auditor should test whether every available tool is necessary.
Remove unnecessary modification functions.
Email sending may not be required.
Ticket-closing permissions may not be required.
Practical rule: a model cannot misuse a capability it does not have.
5. Separate Read Access From Write Access
One of the most useful audit tests is simple:
Can the AI turn information retrieval into an action?
| Permission | Audit Consideration |
|---|---|
| Read | What information can the AI retrieve? |
| Write | What records can it create or change? |
| Delete | Can it remove information or evidence? |
| Export | Can information leave the intended boundary? |
| Approve | Can the AI authorize business actions? |
| Administrative | Can it change access, configuration, or system settings? |
Where possible, separate retrieval workflows from action workflows. High-impact actions should require stronger authorization.
6. Test Human Approval for High-Impact Actions
“Human in the loop” should mean more than displaying an AI response to an employee.
Approval needs to occur before the sensitive action.
1. AI Drafts
The system prepares the proposed action.
2. Human Reviews
An authorized person reviews the output.
3. Action Executes
The system acts only after approval.
The same principle can apply to payments, record deletion, account changes, production deployments, external communications, security changes, and other high-impact operations.
The auditor should also test whether users can bypass the approval.
Practical rule: an approval that exists only in policy is weak. An approval enforced by the workflow is much stronger.
7. Test Direct Prompt Injection
Direct prompt injection occurs when a user deliberately enters instructions designed to override or manipulate an AI workflow.
An auditor does not need to become an advanced AI red-team specialist.
However, the audit can sample realistic cases.
For example, provide conflicting instructions and observe whether the system attempts prohibited actions.
Audit objective: do not simply prove that the model can be manipulated. Determine whether manipulation produces unauthorized access or action.
8. Test Indirect Prompt Injection
Indirect prompt injection deserves even more attention in connected AI workflows.
The malicious instruction may not come directly from the user. It can appear inside information that the AI processes.
NIST’s 2026 AI agent security research highlights agent hijacking, also called indirect prompt injection, as a significant risk when agents process external information and then take actions.
Auditors should therefore identify which untrusted sources can influence an AI workflow and test whether those sources can change the workflow’s behaviour.
Are AI Agents Already Connected to Your Business Systems?
The biggest risk may not be the prompt itself. It may be the permissions, connected tools, or data access behind the AI workflow.
Canadian Cyber can test AI access boundaries before your ISO 27001 internal audit or certification audit.
9. Test Data Boundaries
Prompt injection can expose weak information segregation.
- Can an AI asked to summarize one client’s documents retrieve another client’s data?
- Can a normal user obtain executive files through the AI agent?
- Can a contractor retrieve employee records?
- Can an AI search reach SharePoint sites that the user could not normally access?
The AI layer should not create a shortcut around existing authorization. Downstream systems should continue enforcing access controls.
10. Test Authorization at the Final System
One of the strongest design principles is complete mediation.
The downstream system should verify whether the requested action is permitted.
Example: an AI agent requests a customer record.
The customer platform should independently check whether the current identity is authorized to access that record.
The model should not decide its own authorization. A downstream authorization check limits the impact of prompt injection because manipulated output still encounters a security boundary.
11. Audit AI Logging Differently
Traditional chatbot logging may capture the user’s prompt and the model’s answer.
That is not enough for an agentic workflow.
AI Audit Logs Should Answer:
- Who initiated the workflow?
- Which AI identity acted?
- What data was accessed?
- Which tool was called?
- What authorization decision occurred?
- What action was performed?
- Was human approval required?
- Who approved it?
- What changed?
- Was information sent outside the organization?
Logging only the model response can create an audit trail that appears complete while missing tool calls, access scopes, authorization decisions, and actual business actions.
12. Test the Emergency Stop
Access control is not complete without revocation.
If an AI Workflow Is Compromised, Can You:
- Immediately disable the agent?
- Revoke API credentials?
- Invalidate active tokens?
- Remove tool access?
- Stop automated workflows?
- Identify what the AI accessed before shutdown?
The organization should not need a software development project to stop a compromised AI workflow.
ISO 27001 Controls That May Be Relevant to Prompt Injection
ISO/IEC 27001:2022 does not contain a control called “prompt injection.”
That does not put prompt injection outside the ISMS. The risk should be assessed through the organization’s risk-management process and mapped to applicable controls in its Statement of Applicability.
| ISO 27001 Control Area | AI Audit Connection |
|---|---|
| A.5.15 Access Control | Define how AI systems and workflows receive access. |
| A.5.16 Identity Management | Manage identities used by AI services and agents. |
| A.5.18 Access Rights | Provision, review, modify, and revoke AI access. |
| A.5.23 Cloud Services | Review AI SaaS and cloud-based AI services. |
| A.8.2 Privileged Access Rights | Restrict privileged AI and agent permissions. |
| A.8.3 Information Access Restriction | Prevent AI from retrieving unauthorized information. |
| A.8.15 Logging | Record relevant AI and workflow activity. |
| A.8.16 Monitoring Activities | Detect suspicious AI behaviour and tool use. |
| A.8.26 Application Security Requirements | Define security requirements for AI-enabled applications. |
| A.8.27 Secure Architecture and Engineering | Build authorization boundaries into AI architecture. |
| A.8.29 Security Testing | Test AI workflows before and after material changes. |
| A.8.32 Change Management | Control changes to models, tools, prompts, permissions, and integrations. |
The exact controls should depend on the organization’s AI use, risks, scope, and Statement of Applicability.
Evidence ISO 27001 Auditors Should Request
Evidence should prove how the workflow operates, not simply describe how it was designed.
The auditor should compare documentation with actual system configuration.
A policy stating that “least privilege is required” is not enough if the AI integration still uses an administrator account.
Common AI Workflow Internal Audit Findings
Important: “Do not access confidential records” should not replace technical access restrictions.
ISO 27001 AI Workflow Audit Checklist
- AI workflows are included in the organization’s system inventory and risk assessment.
- Each workflow has a documented business owner and approved purpose.
- AI identities and authentication methods are known.
- Access follows least privilege.
- Privileged access is separately controlled.
- Unnecessary AI tools and functions are disabled.
- Read, write, delete, export, and administrative permissions are reviewed separately.
- Downstream systems independently enforce authorization.
- Direct prompt injection has been tested.
- Indirect prompt injection through emails, files, webpages, tickets, and external data has been considered.
- Sensitive actions require appropriate human approval.
- AI activity, tool calls, and important authorization events are logged.
- Suspicious AI activity can be monitored.
- AI access can be quickly revoked.
- AI vendors and integrations are included in supplier risk management.
- Material AI changes follow change-management processes.
- Findings are entered into corrective-action processes and tracked to closure.
How SharePoint Can Support AI Audit Evidence
AI governance can quickly create evidence across security, IT, compliance, legal, privacy, procurement, and business teams.
A structured ISMS workspace can make that evidence easier to manage.
Canadian Cyber’s ISMS SharePoint Solution can help organizations maintain AI inventories, risk assessments, control mappings, vendor reviews, access reviews, security testing records, incidents, audit findings, corrective actions, policies, approvals, and management-review evidence inside Microsoft 365.
AI Risk → Control → Owner → Evidence → Audit Test → Finding → Corrective Action
That traceability becomes increasingly important as AI workflows become more complex.
Explore Canadian Cyber’s ISMS SharePoint Platform
The Most Important Prompt Injection Audit Test
Prompt injection testing should not end with:
“Did the AI follow the malicious instruction?”
Ask instead:
“What security boundary stopped the AI after the malicious instruction succeeded?”
That boundary may be:
Ideally, several controls work together. This is defence in depth for AI.
Frequently Asked Questions
Is prompt injection covered by ISO 27001?
ISO 27001 does not contain a specific prompt-injection control. However, organizations should assess prompt injection through information-security risk management and apply relevant access control, identity, logging, monitoring, supplier, application-security, and secure-development controls.
Is prompt injection only a problem for public chatbots?
No. The risk becomes especially important when AI systems connect to internal information or business tools. An AI agent that can read email, access files, update records, call APIs, or perform actions may create much greater impact.
What is indirect prompt injection?
Indirect prompt injection occurs when malicious instructions are embedded in content that an AI system processes, such as an email, webpage, document, ticket, repository, or other external source.
Why is prompt injection an access-control problem?
A manipulated AI model becomes more dangerous when it has broad permissions. Strong authorization limits what the workflow can access or change even when the model behaves unexpectedly.
Should AI agents have their own identities?
Where technically appropriate, organizations should use identities that create clear accountability and allow access to be scoped, reviewed, monitored, and revoked. Shared highly privileged identities increase risk.
Should ISO 27001 internal auditors perform AI security testing?
If AI workflows create information-security risks within the ISMS scope, auditors should obtain evidence that those risks and related controls are tested. The depth of technical testing should reflect the organization’s risk, architecture, expertise, and audit objectives.
Can system prompts prevent prompt injection?
System prompts and guardrails can help guide behaviour. However, organizations should not rely on them as the only authorization boundary. Permissions should also be enforced through identities, roles, scopes, tools, downstream authorization, and approval workflows.
From AI Policy to AI Control Evidence
AI security cannot depend on asking a model to behave.
As AI systems gain access to files, emails, APIs, SaaS platforms, databases, and business workflows, organizations need clear authority boundaries.
ISO 27001 internal audit provides a practical way to test those boundaries.
- Inventory the workflow.
- Identify its authority.
- Reduce its permissions.
- Restrict its tools.
- Separate read from write.
- Require approval for high-impact actions.
- Log what actually happens.
- Test prompt injection.
Then verify that technical controls still prevent unauthorized access when the model gets the instruction wrong.
Takeaway: this is how prompt injection becomes an auditable information-security risk instead of an unpredictable AI problem.
Need to Audit AI Workflows Before Your Next ISO 27001 Audit?
Canadian Cyber helps organizations review AI access controls, prompt-injection exposure, AI agents, connected tools, vendor risk, logging, evidence, risk registers, and corrective actions as part of ISO 27001 internal audit and AI governance programs.
We can also help you organize AI governance and audit evidence inside Canadian Cyber’s ISMS SharePoint Solution.
Stay Connected With Canadian Cyber
Follow Canadian Cyber for practical insights on ISO 27001 internal audits, AI security, prompt injection, AI governance, ISO 42001, SharePoint ISMS, cybersecurity risk, and certification readiness.
