SundAIRequest a proposal
Menu

SundAI / Insights

AI AGENTS

Before your AI agent gets access: seven decisions to make

A practical checklist for permissions, approvals and stopping unintended actions.

By SundAI4 min read

The short answer

Before connecting an AI agent to real business systems, decide what it may read, change and send; who approves consequential actions; and how access can be stopped. Start with a bounded workflow and collect evidence before expanding it.

Why this matters in September 2026

NCSC’s August 2026 advice and OWASP’s excessive-agency guidance identify a shared problem: useful automation can also perform unintended actions. Model safeguards alone do not replace independently enforced permissions and operational oversight.

NCSC — Managing the cyber risk of agentic AI (20 Aug 2026) · OWASP — Excessive Agency (2025)

Seven decisions for your deployment review

Use the following as a SundAI review worksheet. For every row, record the owner, the actual configuration and the result of a test. An unanswered question is a gap to resolve, not evidence that the agent is safe.

DecisionEvidence to request
1. What is the job?Write one permitted workflow and explicit stop conditions. List actions that remain outside the task.
2. Which identity acts?Record the agent identity, permissions, credential lifetime and the person who can revoke access.
3. What can it reach?List data sources, systems and external destinations. Confirm access with both permitted and denied test cases.
4. What needs approval?Show the approval step for consequential actions, including the exact recipient, change or transaction being approved.
5. What contains a mistake?Document limits on actions, retries and spending. Test a controlled failure without exposing production data.
6. Who sees what happened?Show an action record with time, identity, tool, decision and outcome. Protect logs and avoid unnecessary personal data.
7. How do you stop it?Demonstrate revocation and shutdown. Name the incident owner and the conditions for restarting.

A realistic example: an agent that prepares supplier replies

Imagine a purchasing team wants an assistant to read supplier emails, consult approved documents and draft replies. In our illustrative design, the first release can read a limited mailbox and create drafts. It cannot send messages, change supplier bank details or grant itself new access. Those are separate capabilities requiring separate decisions. The team tests a misleading attachment, an unavailable source and a request involving another department’s restricted records. A polished draft is useful only when its supporting evidence and permitted scope remain clear.

A useful acceptance test

Ask the implementation team to show a normal successful run and a deliberately blocked run side by side. In the blocked run, the agent should be unable to perform an out-of-scope change even if the generated text asks for it. Save the configuration, result and responsible reviewer. Repeat this demonstration after meaningful changes to the model, connector or permissions. This is a proposed review exercise; it is not a certification test or a guarantee that all failure modes have been found.

What to do with a failed check

Choose a smaller task, add a missing control or keep the workflow in a supervised pilot. A review should finish with a decision, an owner and the evidence still needed. If the business cannot tolerate the remaining risk, do not grant the requested autonomy. The worksheet is designed to make that decision visible.

Review the access around your AI agent

Bring one assistant, agent or supplier to a scoped AI Security Assessment. Discuss data flows, permissions and a prioritised remediation plan.

Request a proposal →

Keep reading

Sources and method

NCSC — Managing the cyber risk of agentic AI (20 Aug 2026) · OWASP — Excessive Agency (2025)

AI-assisted editorial guide by SundAI. Sources checked on 18 September 2026. Evidence confidence: high for the cited descriptions of risks and research; this worksheet and its examples are proposed practice, not measured client outcomes or a security guarantee. Future scenarios are not predictions.