- Start with one low-risk task, a small set of test data and a clear owner. Do not begin with a broad promise to automate work.
- Give the agent only the tools and permissions needed for that task. Keep actions that send, pay, delete or publish behind human approval.
- Test how the agent reacts to bad instructions hidden in emails, files or web pages before you expand its access.
AI agents can do more than answer questions. They can read a shared inbox and look up records. They can draft a reply and call a business tool. That can save time. It also changes the risk. An agent with access can take an action, not just suggest one.
The sensible response is not to ban agents or hand them every permission on day one. Run a narrow pilot. Give it one job, limited data and a named person who can stop it. That approach fits current US and UK guidance. NIST has started work on agent identity and authorization. The UK's AI security code asks teams to risk-assess permissions given to an AI system.
Pick one job that is useful but reversible
Choose a task with a clear result and a low cost if the result is wrong. Good early jobs include sorting internal support requests. They also include preparing a meeting brief from approved notes. Another option is drafting a reply for a person to review. Avoid work that moves money, changes production systems, sends bulk messages or deletes records.
Write the pilot goal in one sentence. For example: "The agent prepares a daily summary of tagged support tickets for one team." Then name a measure. It could be time saved, useful drafts, or errors caught before anything is sent. If the team cannot state the job and measure clearly, the agent is probably too broad for a first pilot.
Give the agent a small permission budget
Least privilege means giving a person or process only the access needed for its task. Apply the same rule to an agent. A summary agent may need read-only access to one folder. It does not need permission to send mail, change calendar events or browse every customer record.
| Pilot need | Safer starting access | Keep out of scope |
|---|---|---|
| Daily internal summary | Read-only access to one approved data set | Sending messages or changing records |
| Drafting a reply | Read the chosen thread and create a draft | Final send permission |
| Booking help | Read free/busy times and suggest slots | Creating or moving calendar events |
Use a separate service account if the tool supports it. Do not connect the pilot to a leader's full account because it is convenient. Record each connected system, permission and owner in a short register. This makes later review possible. It also makes removal easier if the pilot ends.
Keep a human at the action point
For the first version, the agent can prepare a recommendation or draft. A person should approve the final action. This is vital for sending, publishing, purchasing, deleting and changing access. A human review step catches simple mistakes. It also helps the team learn where the agent is unreliable.
Do not treat approval as a rubber stamp. Show the source material, the proposed action and the destination in the review screen. Make the reviewer able to reject, edit or stop the task. Keep a log of the decision and the action taken. This is the same practical habit that helps buyers check vendor claims in our software vendor security evidence guide.
Test for hostile instructions before expansion
An agent can be tricked by instructions hidden in a web page, document or email. This is called indirect prompt injection. NIST describes agent hijacking as a case where untrusted data tries to steer an agent away from the user's real task. It is a reason to test the full workflow, not proof that every agent will fail.
Before adding access, place harmless test instructions in a sample email or document. Try prompts that tell the agent to ignore its task. Also try prompts that ask it to reveal private notes or use an unapproved tool. The correct result is simple. The agent flags or ignores the content. It never acts outside its permission budget. Record what happened. Fix the workflow or reduce access if the result is unclear.
Know when the pilot is ready to grow
Expand only after the agent completes the narrow job reliably. Reviewers should understand its work. The team should also test a bad-input case. Add one new system or action at a time. Repeat the permission review each time. More tools create more useful paths. They also create more ways for a mistake to spread.
Many teams will use a mix: small, focused agents for repeatable work and a more capable model for unusual cases. That is close to the task-routing approach in why small language models are winning inside companies. The goal is not maximum autonomy. It is useful work with boundaries the team can explain.
Sources and further reading
- NIST: AI Agent Standards Initiative
- NIST: Strengthening AI Agent Hijacking Evaluations
- UK Government: AI Cyber Security Code of Practice
- UK Government: Mapping global AI security standards
Frequently asked questions
Should an AI agent have access to a shared inbox?
It can, but start with a small, read-only mailbox or labelled folder. Let it prepare a summary or a draft before you allow it to send anything.
Can prompt injection be fully solved by a system prompt?
No. Strong instructions help, but access limits, approval steps, safe tool design and adversarial testing still matter.