AI Agent Security Starts With Least Privilege

An AI agent that inherits everything its user can do is an insider waiting for a bad input. What the joint guidance from six cyber agencies, including Canada’s, says about scoping agent access, and how to test it before launch.

By Krikor Tengerian · Co-founder, SecuritAI Technologies Ltd. · October 2026

Your finance team set up an agent to handle routine procurement approvals. It runs under a broad service account, so it can read the whole finance drive, send email and approve payments of any size. It has done its job well for a month. The day one of the tools it relies on is compromised, it can do everything that account can.

Most teams set agents up this way for a simple reason: broad access makes the pilot work on the first try. Nobody plans to leave it that way. The trouble is that the pilot becomes production before anyone narrows the permissions.

What six cyber agencies, including Canada’s, said about AI agent security

On May 1, 2026, six national cyber agencies published joint guidance, Careful Adoption of Agentic AI Services. The co-authors are the Canadian Centre for Cyber Security, the Australian Signals Directorate, CISA and the NSA in the United States, and the national cyber security agencies of New Zealand and the United Kingdom.

The guidance puts privilege at the center of AI agent security. It says privilege risks are a key concern for agentic AI and that strict adherence to the principle of least privilege is critical, because the privileges given to an agent directly decide how much risk it can introduce. It recommends never granting agents broad or unrestricted access, especially to sensitive data or critical systems, and starting with low-risk, non-sensitive tasks.

The confused deputy problem

The full guidance walks through a scenario close to the opening example. A procurement agent is given broad access to financial systems, email and contract repositories, and its permissions are only reviewed at deployment. An attacker compromises a low-risk tool in the agent’s workflow and inherits the agent’s excessive privileges, which lets them change contracts and approve payments without triggering alerts.

The guidance calls this a confused deputy: a trusted agent misused to do what the attacker could not do directly. Because every action runs under the agent’s trusted identity, the audit logs look legitimate, and detection is delayed. A second scenario shows an update agent with broad write access deleting firewall logs, simply because a user added that request to a routine patching prompt.

Here is the part people get wrong

Teams try to make the agent safe by instructing it: a longer system prompt, a rule that says “never approve more than $500”. That puts the model in charge of its own limits. A rule written in the prompt is a request. A permission the agent does not hold is a control.

The OWASP Gen AI Security Project makes the same point in LLM06:2025 Excessive Agency: enforce authorization in downstream systems rather than relying on the model to decide whether an action is allowed. The joint guidance goes further and says that decisions about when human approval is required belong to the system’s designers or operators, not to the agent.

Six rules for AI agent security

1. Give every agent its own identity. The guidance recommends building each agent as a distinct principal with its own keys or certificates, kept in a trusted registry, so you can see and limit what each one does. Deny access to any agent that is not in the registry.
2. Start with no permissions. Add only the minimum scope the approved task needs, and review it again when the task changes.
3. Use short-lived credentials. Replace static, long-lived secrets with credentials that expire when the job is done, and require just-in-time credentials for privileged actions.
4. Keep the limits outside the model. Enforce them as hard constraints, deny lists and API-level policies in the systems and gateways the agent calls, so the agent cannot override them.
5. Put a human in front of high-impact actions. The guidance names system resets, network egress and deleting critical records as examples, and recommends holding any request to delete logs or audit records until a person approves it.
6. Watch for drift. Monitor and log identity and privilege changes, isolate high-risk agents, and keep agents away from write access to their own logs.

Expect the risk to change mid-task

Least privilege is the base of AI agent security. It reduces what a compromised agent can reach, but it does not stop an agent from being steered inside the permissions it has. The guidance notes that agents pull data from tools and memory into their context, which widens the opening for prompt injection, and that agents should weigh how trustworthy each data source is.

That is why the guidance pairs access control with input checks, including prompt injection filters and semantic analysis to detect malicious instructions, and with continuous monitoring of what the agent actually does: prompts, tool calls and actions taken, not only its inputs and outputs.

Map AI agent security to the work you already do

You do not need a new program to start. The OWASP Top 10 for Agentic Applications for 2026, published December 9, 2025, gives security teams a shared list of agent risks to plan against. The joint guidance itself recommends fitting agentic AI into your existing security model and risk posture instead of building a separate one.

If your company already reviews user access for SOC 2 or ISO 27001, add agent identities to the same review, with the same owner, scope and expiry questions. Our sister product SecuritComply covers how that evidence is organized for a SOC 2 program in Canada.

Test AI agent security the way an attacker would

Permissions on paper do not tell you what happens when an agent reads a poisoned document. The joint guidance recommends red teaming AI agents, testing their behavior in a sandbox before production, and probing for abilities nobody expected them to have.

AI red teaming includes agent abuse tests, which try to manipulate tool-using agents into actions they should not take, together with prompt injection, data exfiltration and system prompt leakage. Run them before launch and after every new tool or permission. If you want to feel how indirect instructions slip in, try our free prompt injection game.

Where SecuritAI fits

The SecuritAI AI Firewall sits in front of your model as a proxy, outside the model, and inspects every prompt through seven layers, the seventh, output scanning, in development. Its Policy Engine enforces your access rules, including rate limits, allowed countries, time windows and trusted sources. It keeps an exportable audit log, with inspection and log storage in Canada.

It does not replace least privilege, which remains the main control in AI agent security. The permissions an agent holds are set in your identity system and the tools themselves. The firewall adds a control the model cannot talk its way past, and a record of what reached it.

References

1. Canadian Centre for Cyber Security, ASD’s ACSC, CISA, NSA, NCSC-NZ and NCSC-UK, Careful Adoption of Agentic AI Services, May 1, 2026
2. The same guidance, full document (PDF)
3. OWASP Gen AI Security Project, LLM06:2025 Excessive Agency
4. OWASP Gen AI Security Project, OWASP Top 10 for Agentic Applications for 2026, December 9, 2025
5. OWASP Gen AI Security Project, LLM01:2025 Prompt Injection

← Back to the blog