SaaS Security
Prompt Injection
AI Internal Audit
Indirect Prompt Injection in SaaS: 10 Evidence Checks for Internal Audit
Learn how ISO 27001 internal auditors can test indirect prompt injection across SaaS AI workflows, agents, customer data, connected tools, permissions, approvals, logging, and incident response.
A Customer Ticket Can Become an AI Instruction
A customer submits a support ticket.
It looks normal.
However, hidden inside the ticket is an instruction telling your AI assistant to ignore its normal task, search connected records, and return confidential information.
The employee did not enter the malicious prompt.
The attacker did not need access to the AI interface.
The AI simply read content it was already allowed to process.
That is indirect prompt injection.
For SaaS companies, the risk is growing because AI is no longer limited to generating text.
AI assistants and agents can read customer tickets, query knowledge bases, summarize emails, search SharePoint, access CRM records, review documents, call APIs, and trigger workflows.
This changes what internal auditors need to test.
Weak Question
“Do we have AI security controls?”
Better Audit Question
“Can we prove that untrusted SaaS data cannot silently take control of an AI workflow?”
Quick Answer
How Should Internal Audit Test Indirect Prompt Injection in SaaS?
Internal auditors should identify every source of untrusted content that an AI system can read.
They should then test what the AI can access, which tools it can use, what actions it can perform, and which controls limit the impact of malicious instructions.
The audit should review evidence for:
- AI workflow inventories.
- Data-source classification.
- Prompt injection testing.
- Access and tool permissions.
- Human approvals.
- Data segregation.
- AI activity logging.
- Detection and incident response.
- Corrective actions and retesting.
Bottom line: do not ask only whether indirect prompt injection is possible. Test whether a successful injection can cross a security boundary.
Why Indirect Prompt Injection Matters for SaaS
Modern SaaS platforms consume large amounts of external content.
AI systems often process this information automatically.
That creates a trust problem.
Indirect prompt injection can place malicious instructions inside documents, emails, webpages, database records, or other content an AI workflow processes.
The AI may then interpret those instructions as commands.
This becomes especially important when the AI can take action through connected SaaS systems and tools.
A manipulated summarizer may produce a bad summary.
A manipulated AI agent with APIs, customer records, email, files, or administrative privileges can create a much larger security incident.
Who Should Use This AI Internal Audit Guide?
If your AI system reads information that another person or organization can influence, indirect prompt injection should be part of your risk review.
Quick Snapshot: 10 Evidence Checks
| Evidence Check | What Internal Audit Should Verify |
|---|---|
| 1. AI Workflow Inventory | All AI workflows and connected SaaS systems are known. |
| 2. Untrusted Input Sources | External content entering AI workflows is identified. |
| 3. Prompt Injection Testing | Realistic indirect injection scenarios have been tested. |
| 4. Access Permissions | AI identities follow least privilege. |
| 5. Tool Permissions | AI cannot call unnecessary or dangerous tools. |
| 6. Human Approval | High-impact actions require independent approval. |
| 7. Data Segregation | AI cannot cross customer, tenant, or department boundaries. |
| 8. Logging | Inputs, tool calls, actions, and authorization events are recorded. |
| 9. Detection and Response | Suspicious AI behaviour can be detected and contained. |
| 10. Corrective Action | Findings are tracked, fixed, and retested. |
Evidence Check 1: Build an AI Workflow Inventory
Start with visibility.
You cannot test indirect prompt injection if you do not know where AI is being used.
Ask for the organization’s AI inventory, but do not stop at a simple list of product names.
Internal Audit Should Identify
- AI application or model.
- Business purpose.
- System owner and data owner.
- Connected SaaS systems.
- Data and external data sources.
- Tools and plugins.
- API connections.
- Authentication method.
- Read and write permissions.
- Human approval points.
- Customer-facing functionality.
Example: “Microsoft Copilot” is not enough. The auditor should understand whether Copilot can search SharePoint, read email, access Teams content, summarize meetings, or interact with other systems.
Evidence to Request
- AI system register.
- Application inventory.
- AI use-case register.
- Architecture and data-flow diagrams.
- API integration inventory.
- Approved AI tool list.
- AI risk register.
Common finding: AI features exist inside SaaS applications but are missing from the organization’s AI inventory.
Evidence Check 2: Identify Untrusted Input Sources
Indirect prompt injection begins with content.
Internal audit should identify which content sources can influence an AI workflow.
Ask:
What can the AI read?
Who can influence that information?
That second question is critical.
Example AI Support Workflow
Customer ticket → attachment → account information → internal knowledge base → CRM history
The customer controls part of the input. Internal audit should determine whether customer-controlled instructions can influence how the AI interacts with trusted internal information.
Evidence to Request
- Data-flow maps.
- Trust-boundary diagrams.
- Input classifications.
- Approved data-source lists.
- External content controls.
- RAG data-source configuration.
- Connector inventories.
- Knowledge-base permissions.
Evidence Check 3: Perform Prompt Injection Security Testing
A policy saying “prompt injection is prohibited” does not prove that the system is secure.
Internal audit should look for real testing.
Example Test
Place an instruction inside a document the AI is expected to summarize.
The instruction could attempt to:
- Ignore the user’s request.
- Search another data source.
- Reveal confidential information.
- Use another connected tool.
- Send information externally.
- Modify a record.
- Change the intended workflow.
The key question is not simply whether the model follows the malicious text.
What control stops the action after the model has been manipulated?
Evidence to Request
- AI security test plans.
- Prompt injection test cases.
- Penetration test reports.
- Red-team reports.
- Application security results.
- Adversarial AI testing.
- Failed test records.
- Remediation evidence.
- Retest results.
Strong evidence: Test scenario → expected control → actual result → finding → owner → remediation → retest.
Evidence Check 4: Test AI Access Permissions
Assume the prompt injection succeeds.
What can the AI access?
AI needs access to ten CRM fields.
Integration can access the entire customer database.
Support assistant needs read access.
Service account also has update and delete permissions.
This turns prompt injection into an access-control problem.
Required Access ≠ Automatically Approved Access
Evidence to Request
- RBAC configuration.
- Identity records.
- API and OAuth scopes.
- Service-account permissions.
- Privileged access records.
- Access approval records.
- Periodic access reviews.
- Access-removal evidence.
Audit question: if malicious content controls the AI for one request, what information could that AI identity retrieve?
Evidence Check 5: Review AI Tool Permissions
Access to information creates one risk.
Access to tools creates another.
Does this AI workflow actually need this capability?
If the answer is no, the capability should be removed or restricted.
Evidence to Request
- Tool inventory.
- Plugin configuration.
- MCP configuration.
- API function list.
- Tool permissions.
- Tool approval process.
- Disabled-tool evidence.
- Change records.
Good control: a support summarization agent should not receive permission to delete support tickets simply because the SaaS API supports deletion.
Could One Malicious Ticket Control Your AI Agent?
Canadian Cyber can review your AI workflows, connected SaaS tools, identities, API scopes, data boundaries, human approvals, and audit evidence before your next ISO 27001 internal or certification audit.
The objective is simple: prove that malicious content cannot turn excessive AI authority into a security incident.
Evidence Check 6: Test Human Approval
Many organizations say they have a “human in the loop.”
Internal audit should test what that actually means.
Strong Approval Flow
→
AI drafts response
→
Employee reviews
→
Employee approves
→
Separate system sends
Weak Approval Flow
→
AI decides action
→
AI sends response
→
Employee reviews later
That is monitoring, not approval.
High-Impact Actions to Review
- Sending sensitive communications.
- Deleting information.
- Approving financial activity.
- Changing customer records.
- Deploying code.
- Modifying security settings.
- Granting access.
- Exporting sensitive data.
- Executing administrative actions.
Strong approval should be enforced by the workflow, not only described in a policy.
Evidence Check 7: Test Tenant and Data Segregation
For SaaS companies, this is critical.
Suppose Customer A places malicious instructions inside a support request.
Can those instructions cause the AI workflow to retrieve information belonging to Customer B?
If yes, the issue may become a customer data isolation failure.
Test Separation Between
Example Audit Test
Provide the AI with content from Tenant A and attempt to retrieve:
- Tenant B records.
- Administrative data.
- Other customer documents.
- Internal-only knowledge.
- Restricted support notes.
The downstream SaaS application should enforce authorization independently.
Evidence to Request
- Tenant isolation design.
- Authorization testing.
- Application-security test results.
- Row-level security.
- Access-control policies.
- API authorization.
- Data-segregation test cases.
- Multi-tenant penetration tests.
Evidence Check 8: Audit AI Logging
Recording user prompts is only part of an AI audit trail.
For connected workflows, internal audit should determine whether logs show what the AI actually did.
Useful Logs Should Answer
- Who initiated the request?
- Which AI system processed it?
- What external content was retrieved?
- Which identity was used?
- Which tool was called?
- Which API was accessed?
- What information was retrieved?
- What action was attempted?
- Was the action allowed or blocked?
- Was approval required?
- Who approved it?
- Was information sent externally?
Evidence to Request
- AI interaction logs.
- Application logs.
- API and tool-call logs.
- Authentication and authorization logs.
- DLP events.
- Security alerts.
- Approval records.
- SIEM events.
- Retention settings.
Audit test: select one completed AI workflow and reconstruct it from beginning to end using retained evidence.
Evidence Check 9: Test Detection and Incident Response
Prevention is important.
Detection matters too.
Organizations should assume some indirect prompt injection attempts may bypass individual controls.
Possible Warning Signs
Ask your security team:
What happens if an AI assistant tries to retrieve 5,000 customer records?
What if it calls a tool it normally does not use?
What if it suddenly accesses confidential SharePoint locations?
Evidence to Request
- Monitoring rules.
- SIEM and DLP alerts.
- AI security alerts.
- Incident response procedures.
- AI incident scenarios.
- Tabletop exercise results.
- Escalation records.
- Access-revocation procedures.
Evidence Check 10: Corrective Actions and Retesting
Internal audit findings only create value when organizations close them effectively.
Prompt injection findings should enter the same corrective-action process used for other ISMS issues.
| Finding Element | Example |
|---|---|
| Issue | AI support assistant can access CRM records outside the approved workflow. |
| Risk | Malicious customer-controlled content may influence the AI to retrieve unauthorized information. |
| Root Cause | Service account has excessive CRM API permissions. |
| Corrective Action | Create a dedicated identity with read-only access to approved support fields. |
| Owner | SaaS Engineering Manager. |
| Due Date | Defined according to risk. |
| Verification | Repeat prompt injection and authorization testing. |
Evidence to Request
- Internal audit findings.
- Corrective-action register.
- Root-cause analysis.
- Assigned owners.
- Target dates.
- Closure evidence.
- Retest results.
- Risk acceptance approvals.
- Management-review records.
Practical rule: closing the ticket is not enough. Internal audit should verify that the control now works.
How Indirect Prompt Injection Maps to ISO 27001
ISO/IEC 27001:2022 does not contain an Annex A control titled “Indirect Prompt Injection.”
That does not mean the risk sits outside the ISMS.
Organizations should assess the risk and determine which controls apply based on their architecture, scope, risk assessment, and Statement of Applicability.
| ISO 27001 Control | Indirect Prompt Injection Audit Connection |
|---|---|
| A.5.7 Threat Intelligence | Monitor emerging AI and prompt-injection threats. |
| A.5.15 Access Control | Restrict AI access based on business requirements. |
| A.5.16 Identity Management | Control identities used by AI agents and integrations. |
| A.5.18 Access Rights | Review and revoke AI access appropriately. |
| A.5.19 Supplier Relationships | Review AI and SaaS supplier risks. |
| A.5.23 Cloud Services | Govern SaaS and cloud AI services. |
| A.5.24 Incident Management Planning | Include AI incidents in response planning. |
| A.8.2 Privileged Access Rights | Restrict privileged AI permissions. |
| A.8.3 Information Access Restriction | Prevent unauthorized data retrieval. |
| A.8.15 Logging | Record AI and connected-system activity. |
| A.8.16 Monitoring Activities | Detect unusual AI behaviour. |
| A.8.25 Secure Development Life Cycle | Include AI risks during development. |
| A.8.26 Application Security Requirements | Define security requirements for AI workflows. |
| A.8.27 Secure Architecture | Build trust and authorization boundaries into AI systems. |
| A.8.29 Security Testing | Test prompt injection and related controls. |
| A.8.32 Change Management | Control changes to models, prompts, tools, and integrations. |
Practical rule: make the risk visible, assign relevant controls, collect evidence, test effectiveness, and improve the system.
What Strong AI Audit Evidence Looks Like
Weak Evidence
“Our AI vendor protects against prompt injection.”
Strong Evidence
AI workflow → external input → risk assessment → control → configuration → test → log → finding → corrective action → retest.
That evidence chain demonstrates that the organization understands both the risk and the control environment.
Common Indirect Prompt Injection Audit Findings
Teams know the AI model but not which external data it processes.
The workflow can access systems and functions it does not need.
Normal functionality is tested, but adversarial content is not.
Downstream systems assume AI-generated requests are authorized.
The organization has not tested whether AI can cross customer boundaries.
The documented review process can be bypassed technically.
User prompts are logged, but AI actions are not.
Corrective actions are closed without verifying effectiveness.
AI is adopted without updating vendor assessments.
The AI is told not to access information that its technical permissions still allow.
A prompt is not an access-control system.
Internal Audit Evidence Pack for AI-Enabled SaaS
Before completing an AI-enabled SaaS internal audit, consider requesting evidence such as:
You do not need every document for every AI workflow. Evidence should be proportional to the risk.
How SharePoint Can Help Manage AI Security Evidence
AI security evidence can quickly become fragmented.
Architecture records
Testing and monitoring
Access records
Vendor assessments
Risks and findings
Approvals and oversight
A structured ISMS workspace can bring these records together.
Canadian Cyber’s ISMS SharePoint Solution can support:
- AI system and use-case registers.
- AI risk registers.
- AI vendor reviews.
- Prompt injection testing records.
- Access review evidence.
- Security testing.
- AI incidents.
- Corrective actions.
- Policy libraries.
- Approval workflows.
- ISO 27001 evidence.
- ISO 42001 readiness evidence.
- Management dashboards.
AI Workflow → Risk → Control → Evidence → Test → Finding → Owner → Corrective Action → Closure
Explore Canadian Cyber’s ISMS SharePoint Solution
10 Questions Internal Auditors Should Ask
- Which external content sources can influence our AI systems?
- Have we tested malicious instructions inside those sources?
- What information can the AI identity access?
- Which tools can the AI call?
- Can customer-controlled content cause an AI to take action?
- Can the AI cross customer or tenant boundaries?
- Which sensitive actions require human approval?
- Can we reconstruct an AI action from our logs?
- Would we detect unusual AI behaviour?
- Have identified weaknesses been fixed and retested?
If the organization cannot answer these questions with evidence, the AI workflow may not be audit-ready.
Frequently Asked Questions
What is indirect prompt injection?
Indirect prompt injection occurs when malicious instructions are placed inside content that an AI system later reads. The content may be an email, document, webpage, support ticket, database record, knowledge-base article, or another data source.
How is indirect prompt injection different from direct prompt injection?
Direct prompt injection happens when someone gives malicious instructions directly to an AI. Indirect prompt injection reaches the AI through another source of information.
Why is indirect prompt injection dangerous for SaaS companies?
SaaS AI systems often connect to customer data, APIs, support tools, CRMs, knowledge bases, files, and workflow automation. Excessive permissions can turn a malicious instruction into a much larger security event.
Does ISO 27001 require prompt injection testing?
ISO 27001 does not prescribe a specific test named prompt injection testing. However, organizations should identify relevant information-security risks, select appropriate controls, and evaluate whether those controls operate effectively.
What evidence should an ISO 27001 auditor request for AI security?
Relevant evidence may include AI inventories, risk assessments, architecture diagrams, API scopes, permissions, tool inventories, prompt injection tests, logs, vendor reviews, incident records, access reviews, change records, audit findings, and corrective actions.
Can a SaaS company rely only on its AI provider to prevent prompt injection?
No single vendor control should be treated as complete protection. Defense in depth should combine restricted access, controlled tools, authorization, monitoring, data isolation, testing, and human approval for sensitive actions.
Should AI agents have read-only access?
Where a business use case only requires information retrieval, read-only access can significantly reduce risk. Write, delete, export, administrative, and execution permissions should be separately justified.
Can indirect prompt injection cause a data breach?
Potentially. If an AI workflow can access sensitive information and a malicious instruction successfully changes its behaviour, weak authorization or tool controls may allow information to be exposed or actions to be performed.
What is the most important indirect prompt injection control?
There is no single perfect control. The strongest approach is defense in depth: restrict access, limit tools, enforce authorization outside the model, separate customer data, require approval, monitor behaviour, log activity, and test the system.
Can Canadian Cyber audit AI-enabled SaaS environments?
Yes. Canadian Cyber can help SaaS organizations review AI governance, ISO 27001 controls, access, vendor risk, AI workflows, security evidence, internal audit findings, corrective actions, and ISO 42001 readiness.
The Takeaway
Indirect prompt injection changes how SaaS companies should think about AI security.
The malicious instruction may not come from an employee.
It may already be sitting inside a customer ticket, document, webpage, email, knowledge base, database, or connected application.
Organizations should therefore assume that AI systems may eventually process hostile content.
The Real Test Is What Happens Next
- Can the AI access sensitive data?
- Can it cross tenant boundaries?
- Can it call powerful tools?
- Can it modify records?
- Can it send information externally?
- Will another control stop it?
- Will security teams detect it?
- Can the organization prove what happened?
Inventory the workflow. Identify untrusted data. Test the attack. Restrict authority. Verify authorization. Log the activity. Detect abnormal behaviour. Correct the gaps. Retest the controls.
That turns indirect prompt injection from an unpredictable AI threat into a risk the organization can govern, audit, and improve.
Is Your SaaS AI Workflow Ready for Internal Audit?
Canadian Cyber helps SaaS and AI-enabled organizations test whether their AI governance and security controls are actually working.
Our team can support:
- ISO 27001 internal audits.
- AI governance internal audits.
- SaaS security assessments.
- Prompt injection and AI control reviews.
- AI access-control reviews.
- AI vendor risk assessments.
- Shadow AI assessments.
- ISO 42001 readiness.
- Corrective-action support.
- SharePoint ISMS implementation.
- SharePoint AI governance workspaces.
- vCISO advisory services.
Stay Connected With Canadian Cyber
Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, SaaS security, AI governance, prompt injection, ISO 42001, SharePoint ISMS, vCISO services, and cybersecurity risk management.
