Policy Templates: Governance by Default — Agent 365: Governance and Security

The safest time to govern an agent is before it does any work. Once an artificial intelligence (AI) agent is already running, every missing owner, excessive permission, and unclear boundary becomes an active risk. Policy templates change the order of operations: security teams define the rules once, information technology (IT) teams apply them during onboarding, and the agent begins life with the approved configuration already in place.

The problem with governing after launch

Many organizations still govern new systems in two steps. First, a team gets the system working with whatever access is convenient. Later, a review checks whether that access is appropriate. That pattern is familiar, but it is a poor fit for agents because agents can act, retrieve data, call tools, and repeat those actions quickly.

A later review may find the problem, but it cannot erase the time when the agent was already operating with the wrong permissions. If the agent had too much access for three weeks, the organization carried three weeks of unnecessary exposure.

Policy templates are a way to remove that delay. They make the first approved configuration the first real configuration, so the agent is governed before it starts work rather than corrected after it has already been useful, risky, or both.

⚠️

The review gap. A review that happens later can reduce future risk, but it does not protect the period before the review.

Reviewing access after an agent is live leaves an exposure window; applying a template first removes it.

What a policy template is

A policy template is a reusable definition of governance requirements for a particular kind of agent. It describes what that agent should be allowed to do, which resources it can reach, and which management settings must follow it when it is brought into service.

The important idea is not that templates are complicated. The important idea is that they turn a judgment into a reusable control. A security team decides once what a sales-support agent, finance-analysis agent, or service-desk agent should receive. Then each new agent of that type inherits the same approved bundle.

This is similar to an identity blueprint, but one layer higher. An identity blueprint standardizes the identity an agent is stamped from. A policy template standardizes the governance policy that surrounds that identity.

Access packages are the concrete example

In Microsoft Entra, the concrete example of a policy template is an access package. An access package is a predefined bundle of permissions and settings that represents what a given kind of agent should be allowed to do.

Instead of asking an administrator to assemble permissions one at a time for every new agent, the approved bundle is captured in one object. Applying that object gives the new agent the intended access pattern in a repeatable way.

This matters because manual configuration is where inconsistency enters. Two careful administrators can still make slightly different choices. A reusable access package reduces that variation by making the approved choice explicit and repeatable.

The security team defines the governance requirement.
The access package captures the approved permissions and settings.
The onboarding process applies the package to the new agent.
The agent starts with the intended access instead of waiting for later cleanup.

Onboarding is the enforcement point

Onboarding is the process of bringing a new agent into service. In governance by default, onboarding is not just a registration step. It is the moment when the organization attaches the approved policy template to the agent.

This sequencing is the central design choice. The template is applied before the agent begins normal work, so compliance is not dependent on a future reminder, ticket, audit, or quarterly access review.

That does not mean reviews become useless. Reviews still help confirm that templates remain correct, that agents still need what they were granted, and that the operating model has not drifted. The difference is that the baseline is correct from day one.

The approved template is attached during onboarding, so the baseline is correct from day one.

Closing the gap between deployed and governed

The main risk that templates remove is the gap between deployment and governance. In a review-based model, an agent can exist in an uncertain state: it is live, but nobody has yet confirmed whether its access is right. That is where excess permission, missing ownership, and unclear purpose tend to hide.

An over-permissioned agent does not become harmless because a review is scheduled. Until the review happens, the agent can still be misused, tricked, or misconfigured. The organization is relying on future correction while present risk continues to accumulate.

When the template is applied during onboarding, that gap disappears for the baseline configuration. The agent may still need monitoring, audit, and periodic reassessment, but it never has an initial period where it is simply waiting to become governed.

The consistency payoff

Templates also solve a scale problem. A small number of agents can be configured carefully by hand, though even then mistakes happen. A large and growing agent estate cannot depend on every administrator making the same judgment in the same way every time.

With policy templates, one team writes the approved access pattern once. Every agent of that kind receives the same pattern. When the organization changes the policy, it updates the template so future agents receive the new baseline automatically.

This is governance by default in practical terms. It is not necessarily more rules. It is the same approved rules applied reliably, repeatedly, and early enough to matter.

✅

Scale benefit. The larger the agent population becomes, the more valuable it is to replace repeated judgment with reusable approved patterns.

One team defines the pattern; every agent inherits it, and updating the template refreshes the baseline.

Decisions leaders and practitioners must make

Policy templates do not design themselves. Leaders and practitioners still need to decide which categories of agents deserve their own templates, who is allowed to change those templates, and how changes are tested before they become the default for future agents.

A useful starting point is to group agents by job and risk, not by who built them. An agent that summarizes public web content does not need the same template as an agent that reads customer records or triggers workflow actions. The template should reflect the work the agent is expected to perform and the harm it could cause if misused.

Teams also need an exception process. If every unusual request becomes a permanent one-off, the organization drifts back into manual governance. If no exceptions are possible, teams may route around the system. The practical middle ground is to make exceptions explicit, time-bound, owned, and reviewable.

Which agent types need distinct policy templates?
Who owns each template and approves changes to it?
What evidence is required before a template is used in production?
How are exceptions granted, expired, and reviewed?
How often are templates checked against current business and security requirements?

Group agents by the work they do and the harm they could cause, not by who built them.

Templates are a baseline, not the whole program

A policy template is the starting control, not the only control. Agents still need observation, threat detection, audit records, data protection, ownership, and lifecycle management. A well-designed template reduces the chance that an agent starts in a dangerous state, but it does not prove that the agent will always behave as expected.

This distinction matters. Governance by default should not be confused with governance by assumption. The template establishes the approved starting point. Monitoring and review confirm whether that starting point remains appropriate as the agent, its tools, and its business purpose change.

The strongest model combines both ideas: use templates to prevent avoidable initial risk, and use ongoing controls to detect drift, misuse, and changing requirements over time.

Key takeaways

Policy templates let security teams define agent governance requirements once and reuse them consistently.
In Microsoft Entra, an access package is the concrete example: a predefined bundle of permissions and settings for a type of agent.
Applying the template during onboarding makes the agent compliant from its first working moment.
Template-based governance removes the risky gap between deployment and later review.
Templates improve consistency at scale by replacing repeated manual setup with approved reusable patterns.
Policy templates are a baseline control and should be paired with monitoring, audit, reviews, and lifecycle management.

Glossary

Artificial intelligence: Artificial intelligence is software capability that performs tasks commonly associated with human reasoning, such as interpreting information, generating responses, or choosing actions.
Agent: An agent is a software entity that can act on behalf of a user, process, or organization by using data, tools, and permissions.
Policy template: A policy template is a reusable definition of governance requirements that can be applied to every agent of a given kind.
Access package: An access package is a predefined bundle of permissions and settings in Microsoft Entra that can be assigned to an agent during onboarding.
Microsoft Entra: Microsoft Entra is Microsoft's identity and access product family, including services used to manage identities, permissions, and access governance.
Onboarding: Onboarding is the process of bringing a new agent into service and applying the required identity, access, and governance settings.
Governance by default: Governance by default means the approved controls are applied automatically from the start rather than added later as a cleanup task.
Identity blueprint: An identity blueprint is a reusable pattern for creating agent identities with consistent identity properties and requirements.
Lifecycle management: Lifecycle management is the practice of controlling how an agent is created, changed, reviewed, and retired.