Treat AI Agents Like Principals With Permissions, Not Helpful Colleagues

An expense agent that can read receipts may need to check policy and prepare a reimbursement. It probably does not need the same broad access as the employee who requested it. That is the operational point behind Microsoft’s October “agentic insider” framing: an agent need not be malicious to create insider-scale risk. It may misread instructions, encounter hostile content, call the wrong tool or simply have more authority than its task requires.

The security boundary belongs outside the model

Microsoft’s security post argues for wrapping non-deterministic model behavior in deterministic controls: identity, scoped permissions, data boundaries, endpoint and network restrictions, runtime isolation, and action monitoring. Its four operational questions are practical: which agents exist and who owns them; what each can access before acting; which data and systems lie on the path; and how controls should adapt as context changes. Microsoft says Project Perception and Agent 365 share signals and registry information, but that product description is a vendor claim, not independent proof of efficacy. ^[1]

Microsoft Learn describes Perception as a system of specialized agents that can investigate, recommend and, in some cases, act through playbooks, with human approvals and session oversight. That points to another boundary worth preserving: a security agent is itself software with an identity, tools and permissions. It should not be granted unreviewable authority just because its job is “security.” ^[2]

Identity is the anchor. A workload should have an identity distinct from the human who owns or triggered it. That identity lets the organization attach policies, detect stale agents, attribute actions and revoke access without changing the user’s account. Microsoft’s agent identity documentation describes this class of workload principal. The exact implementation depends on the platform, but the principle is portable: avoid shared human credentials and opaque service accounts. ^[3]

A small control loop teams can implement

Start with an inventory that records each agent’s owner, business purpose, runtime, tools, data classes, credential source and review date. If an agent cannot be found in an inventory, it cannot be governed consistently. Then grant only the actions needed for its narrow task. A support agent that drafts a response can prepare a refund request without possessing permission to issue every refund.

Next, make actions observable. Log the request, tool selected, resource accessed, result and any approval or denial. Preserve enough context to reconstruct a decision while applying the organization’s retention and privacy rules. Treat tool output and retrieved content as untrusted inputs; they can contain instructions that attempt to redirect the agent.

Finally, put a human gate around irreversible or high-impact actions: sending a message externally, changing payroll, deleting records, moving money or modifying production access. The gate should show the target and consequence, not merely ask “approve?” A safety system that can silently approve its own work is not a meaningful separation of duties.

OWASP’s agentic application risks likewise emphasize excessive agency, insecure tool use, identity abuse and failures around delegated authority. That list is useful as a threat-model prompt, not a certification checklist. ^[4]

“Continuous” does not mean every action needs another model

There is a temptation to place a guardian agent in front of every action and assume that another language model can detect the first model’s mistakes. That adds latency and complexity without guaranteeing independent judgment. Prefer ordinary controls wherever possible: allowlists, transaction limits, schema validation, isolated execution, rate limits and deterministic approval policies. Use a model to help interpret context where it adds value, then enforce the resulting decision with controls the acting model cannot override.

Measure the whole workflow: blocked unsafe actions, legitimate tasks incorrectly denied, time to detect a misconfiguration, and how quickly access can be revoked. A dashboard of agent activity is not the same as reduced risk. Nor does a vendor’s description of a system as “real time” establish that every connected tool or data source is covered.

A useful test before deploying an agent

Ask the team to demonstrate one ordinary task, one ambiguous request, one malicious instruction embedded in retrieved content, and one unavailable dependency. In each case, verify the agent’s identity, permitted actions, audit record, escalation path and stop mechanism. If the agent can access more than it needs, fix that first. The safest agent is not the one with the most reassuring personality; it is the one whose authority remains bounded when its reasoning goes wrong. See also our guide to protecting data boundaries in agent workflows.