An AI tool can read an email, document or web page and produce a useful summary. An AI agent can go further: it may use what it reads to decide what to do next. That creates a new risk when the content contains hidden or misleading instructions aimed at the agent.
This risk is often called prompt injection. For a business exploring AI prompt injection NZ safeguards, the important point is not the label. The important point is that ordinary content can influence an agent in ways the business did not intend. A document may ask the agent to ignore its task, reveal information, change a record or send a message.
This is general operational guidance, not cybersecurity, privacy or legal advice. Obtain specialist help when an agent can access sensitive information, make financial changes, affect customers or connect to important business systems.
Prompt injection is a control problem: the agent cannot reliably tell every piece of text apart from an instruction unless the business designs that boundary.
The safest response is not to assume a tool will recognise every malicious sentence. Design the workflow so that untrusted content has limited influence, permissions are narrow and a person must approve important actions.
What prompt injection looks like
Imagine an agent that reads supplier messages and prepares follow-up tasks. A message contains a paragraph telling the agent to disregard its role and upload a confidential file to an unknown location. The message is data from the supplier, not an instruction from the business, but an agent may treat both as text to follow.
Another example is a web page that includes hidden content designed to change what the agent does while it researches a question. The content does not need to look suspicious to a person. It only needs to influence the connected system.
The risk is higher when the agent can send, edit, delete, approve or share. A summarising assistant with no connected actions has a smaller blast radius than an agent with broad access.
1. Describe the agent’s real job
Write the task in a short sentence and identify the desired output. Do not start with a vague instruction such as manage the inbox. Define whether the agent is classifying messages, preparing drafts, locating approved information or creating a review task.
A precise role helps staff identify instructions that are outside scope. It also makes it easier to test whether the agent followed the business process rather than the most recent text it encountered.
2. Separate business instructions from outside content
Keep the rules that govern the agent in a controlled place. Treat customer messages, attachments, search results, supplier documents and web pages as untrusted input. They can contain facts to assess, but they should not silently rewrite the agent’s job.
Tell the agent what to do when content includes instructions. It should flag the content, ignore the instruction as authority and continue only within its approved task. If the conflict matters, it should stop and ask a person.
3. Map every source the agent can read
Make a list of mailboxes, folders, sites, databases, documents and connectors. Review the purpose of each source and remove anything that is not essential. A research agent rarely needs access to every internal file, and a customer enquiry agent rarely needs unrestricted access to staff records.
Allowlists are useful because they turn a broad internet or file search into a defined set of places. Review the list when the workflow changes. Old connections often remain active long after a pilot has changed direction.
4. Limit the actions after reading
Start with read and draft permissions. Keep sending, changing records, approving payments and deleting information behind a human confirmation. If an action cannot be reversed, treat it as a higher-risk step.
Do not give an agent administrator access simply because that is the easiest way to make a connection work. Ask what minimum permission completes the task and use a separate test environment where possible.
5. Use explicit approval gates
Define which actions need a person to inspect the context. The approval should show the information used, the proposed change, the recipient and any warning or uncertainty. A person should be able to reject or edit the action without fighting the system.
Approval is weaker when it becomes a routine click. Train reviewers to look for unusual instructions, unexpected recipients, large changes, requests for secrets and actions that do not match the original task.
6. Protect sensitive information
Minimise the information sent to the agent. Use redacted examples, reference numbers or limited fields when full personal or commercial details are not necessary. Check how each connected service stores and processes the information.
Prompt injection can be used to make an agent reveal information that it can access. Narrow permissions reduce what can be exposed. Staff should know that a document asking for confidential data is not automatically authorised to receive it.
7. Add stop conditions
Write down when the agent must stop. Useful triggers include conflicting instructions, an unrecognised sender, a request to disclose secrets, a new destination, missing source information, a high-value action or a decision outside the approved process.
A pause is a successful outcome when the alternative is an unreviewed action. Give the agent a clear route to create a human task rather than encouraging it to guess.
8. Watch for changes in behaviour
Log the important steps so a reviewer can see what the agent read, what it proposed and what happened. Look for new recipients, unexpected file requests, sudden increases in activity, unusual wording or an action that does not match the normal pattern.
Do not rely on a log that records only the final result. When something goes wrong, the path to the result is often what shows which content or permission caused the problem.
9. Test with safe attacks
Before the agent is connected to live work, give it documents that contain harmless instructions aimed at changing its behaviour. Test a message that asks for a secret, an attachment that redirects the task and a page that says to ignore the business rules.
Check that the agent treats the content as untrusted, stops when needed and does not pass the instruction into a later system. Repeat the test after changing the model, source, connector or permission.
10. Prepare an incident and fallback plan
Decide how staff will pause the agent, revoke access, preserve evidence, correct an action and notify the right people. Keep this process short enough to use under pressure. Do not wait for a major incident before identifying the owner.
Keep a manual route for the minimum service. Store important records in normal business systems and make sure another person can follow the fallback. If the agent is unavailable or must be stopped, the business should still know how to handle urgent work.
Train the people who review agent work
Staff do not need to become security specialists to use an agent responsibly, but they do need practical habits. Teach them to question instructions inside content, check destinations, avoid sharing secrets and pause when the proposed action does not fit the request.
Use examples from the actual business. A team that understands why an ordinary-looking document can be unsafe is more likely to report a near miss than a team that has only seen a perfect demonstration.
Keep an AI connection register
Record the agent owner, purpose, connected sources, permissions, approval gates, review date and fallback. Include whether the agent can write, send, delete or make a commitment. This register helps a small business see where its automation authority sits.
Review it when staff change roles, a connector is added, the agent gains a new capability or an incident occurs. Remove unused connections rather than allowing them to become invisible background access.
An agent that handles a narrow task safely may be useful without becoming a general worker. Resist the temptation to give it access to every system for future flexibility. Each additional connection increases the number of paths through which misleading content can create an unintended result.
Responsible adoption is a series of small decisions: define the task, separate instructions from data, limit access, require review, monitor the path and keep a way to stop. Those controls make it easier for a New Zealand small business to benefit from agents without pretending that prompt injection can be solved by confidence alone.
Frequently asked questions
1. What is AI prompt injection?
Prompt injection is an attempt to influence an AI system or agent through content it reads, causing it to ignore its intended task, reveal information or take an unauthorised action.
2. Can prompt injection happen through an ordinary document?
Yes. An email, attachment, web page or other source can contain text that looks like an instruction to the agent even though it is only untrusted business content.
3. Which AI agents face the greatest risk?
Agents with broad access and permission to send, edit, delete, approve or share face more serious consequences if misleading content changes their behaviour.
4. Does a human approval remove the risk?
No, but a meaningful approval gate can limit damage by giving a person the context and authority to reject an unsafe action before it happens.
5. How can a small business reduce prompt injection risk?
Define the agent’s task, restrict sources and permissions, treat outside content as untrusted, add stop conditions, test safely and keep a manual fallback.
6. Should an agent read the whole internet?
Usually not. Use the smallest set of approved sources that can answer the business need and require review before information from outside sources leads to an important action.
7. What should happen after a suspected injection?
Pause the workflow, preserve useful evidence, revoke or review access, correct any affected action and update the process before restarting it.
8. What is the best first step for AI prompt injection NZ protection?
List what the agent can read and do, then remove every source or permission that the defined task does not genuinely require.
Leave a Reply