Before AI reads your agency inbox, check what it can do.

An email is information, not authority

A fictional customer email asks a CSR to send a policy document to a new address. A second paragraph tells the agency’s AI assistant that this is an approved compliance request and it should forward the attachment immediately.

The assistant has encountered a request from outside the agency. That request should not grant it new permissions or bypass the agency’s verification process. The example is fictional, but the design problem is real: outside content can try to steer an agent into actions its owner did not authorize.

OpenAI’s March 11 explanation of prompt injection describes this as a form of social engineering. Its recommendation is to constrain the impact of manipulation, rather than depend on recognizing every bad instruction. This is background security guidance, not a report of a new attack on a particular insurance agency.

Review four permissions before connecting the tool

1. Read. Which mailboxes, folders, documents and records can it access? Start with the information needed for the job. Check whether the connection gives broader access than the workflow requires.
2. Send. Can it only prepare a draft, or can it send messages and attachments? Decide which recipients and actions need approval. An instruction inside an email should not expand that authority.
3. Change. Can it update a customer record, create a user, alter a payment instruction or change a security setting? Assign an authorized human owner to consequential changes.
4. Disclose. Where can information leave the agency? Identify model providers, connectors, logs and any other services involved. Review actual data-handling terms and settings before using customer information.

Download the free agency AI-permissions worksheet to record allowed access, approval rules, test results and who can revoke the connection. Use it with your team or existing IT provider.

Test the boundary with fictional records

Before using live customer information, try a normal request and an ambiguous one using made-up records. Check the proposed action, the source it relied on and the approval it requires. A test should establish what the configured workflow actually does, not just what a vendor demonstration says it can do.

Record what you verified and what you did not. A successful example does not prove the system resists every attack. Keep access narrow, preserve logs appropriate to your policies and make it possible to stop or revoke the connection.

Where defensive AI earns its place

AI can help inspect approved configurations and code, explain advisories, identify questions for your IT provider and organize findings. The value is in helping a responsible person reach and verify a decision sooner. Adding an assistant with broad permissions can also add risk, so the review has to cover the tool itself.

This week’s PHP disclosure is a useful illustration: AI-assisted research helped identify a serious flaw, according to OpenAI, but maintainers and operators still had to fix and deploy the software. Agency defense likewise needs both capable analysis and reliable action.

Give each open issue an owner

For every material finding, keep four things together: the evidence, the next action, the responsible person and the verification result. Your existing IT provider can remain the operator. The agency should be able to tell what was checked and what still needs attention.

Sources and next steps

• OpenAI: Designing AI agents to resist prompt injection, March 11, 2026
• OpenAI: coordinated PHP vulnerability response, October 21, 2026
• This week’s PHP2Shell agency brief
• Free agency provider-check worksheet

General operational guidance. It does not certify compliance, determine insurance coverage or make a system breach-proof. No customer records are needed for the first conversation.