Per-Agent Policy

What Per-Agent Policy Means in Practice

Per-agent policy is a way to treat each AI agent as a separately governed actor, rather than giving every agent the same default permissions. That matters because an agent’s tool access, data access, approval requirements and revocation conditions should reflect its job, its trust level and its operational scope, not just the fact that it is part of the same platform.

This model is especially important once agents are allowed to act across multiple systems. A narrowly scoped policy reduces unnecessary standing access, makes escalation more visible, and gives security teams a clear place to express differences between low-risk automation and higher-impact actions that need explicit oversight.

Why Per-Agent Policy Exists

The core problem it solves is overgeneralisation. If one policy is applied to every agent, the organisation usually ends up with either too much access for simple agents or too much friction for critical ones. Per-agent policy lets teams define distinct boundaries for each agent’s purpose, so a support bot, a developer assistant and a transaction-processing agent can be governed differently.

That distinction is not just administrative. It shapes what each agent can see, what it can attempt, and what happens when the agent reaches a sensitive step. In a well-formed policy model, the policy is part of the agent’s operating design, not a bolted-on exception list.

Policy Scope and Control Points

A strong per-agent policy usually covers four things: allowed tools, allowed data, approval triggers and revocation conditions. Tool scope determines which actions an agent may invoke. Data scope determines which records, prompts, files or services it may read. Approval rules define when a human must confirm a step. Revocation conditions define when the agent’s access should be paused or removed.

These control points work best when they are enforced at runtime, close to the actual action. The policy should not rely on the agent “remembering” instructions in a prompt. It needs an enforcement layer that can decide whether a given call is allowed for that specific agent, in that specific context, at that moment.

For agent runtime controls and policy enforcement patterns, see Tool-Call Security for AI Agents and Agent Controls and Monitoring.

How It Relates to Agent Governance

Per-agent policy becomes more valuable as agent fleets grow, because governance problems multiply quickly when access is shared, duplicated or implicitly inherited. A policy per agent makes ownership clearer, simplifies review, and gives defenders a cleaner audit trail for deciding which agent was allowed to do what. It also supports lifecycle decisions such as onboarding, re-scoping and retirement.

This is also where identity design matters. If two agents have different functions, they should not collapse into the same access profile just because they operate in the same product. Clear per-agent policy helps preserve attribution, constrain blast radius and make revocation meaningful when an agent is no longer trusted.

For policy templates and identity-aware governance patterns, see Agentic AI Security Policy Template, Top 10 Agent Identity Controls and Enterprise-Managed Authorisation for AI Agents.

Common Failure Modes

Per-agent policy fails when it exists only as documentation, when the policy is too coarse to express meaningful differences, or when agents can bypass enforcement through indirect paths. Another common failure is policy drift, where the agent’s actual tool use expands over time but the governing rules do not change with it. Human approval requirements can also be weakened if the approval is not bound to the exact action being authorised.

In practice, the most dangerous failure is policy reuse without review. Reusing a permissive policy across multiple agents can make a small configuration mistake propagate into a large access problem. That is why per-agent policy should be treated as a control boundary, not a naming convention.

Where shared access or oversized credentials are a concern, see Shared credentials between AI agents and Credential Vaulting for AI Agents.

Risk and Threat Considerations

Per-agent policy reduces blast radius, but only if the policy is actually enforced and kept current. The main risk is that an overbroad or stale policy allows an agent to reach tools, data or workflows that exceed its intended role, which can turn a single compromised or misused agent into a wider control failure.

Failure mechanism: The policy is too permissive, too generic, or not bound to the runtime action, so the agent can invoke tools or access data beyond its intended scope. If approvals are weakly implemented, an attacker or malfunctioning agent can use that gap to move from routine automation into higher-impact operations.

Impact: Excessive agency can lead to data exposure, unauthorised actions, weakened auditability and faster lateral expansion of damage across connected systems. In the worst case, a policy mistake becomes a standing privilege problem for an entire class of agents rather than a single workflow issue.

Practitioner Guidance

Governance implication: Give each agent an explicit policy owner, a clearly bounded action profile and a revocation path that can be exercised without waiting for a broader platform change. That makes the policy reviewable as a control object, not just a configuration artifact.

What to watch for: Watch for agents that accumulate tool access faster than their purpose changes, especially when teams copy policies between agents or rely on prompt instructions instead of runtime enforcement. Per-agent policy is strongest when it is narrow, testable and directly tied to the agent’s actual authority.

Practitioner takeaway: Treat per-agent policy as a living access boundary, and review it whenever the agent’s tools, data sources or approval needs change.

Related resources from NHI Mgmt Group

• When should organisations prioritise centralized MCP policy enforcement over per-agent inspection logic?
• Should organisations treat per-cloud policy tuning as enough for AI agent governance?
• Who should own approval policy for autonomous agent actions, IAM or application teams?
• How should organisations enforce AI policy compliance across employee and agent use?