Policy Profiles and packs
Policy Profiles are the customer-facing way to apply runtime controls to a specific audience without duplicating the organization-wide Base Policy.
Policy Profiles are the customer-facing way to apply runtime controls to a specific audience without duplicating the organization-wide Base Policy.
Use Base Policy for the minimum standard every session should inherit. Use Policy Profiles when a real audience needs different runtime behavior. Policy packs remain the internal packaging layer behind profiles.
Mental model
| Layer | Purpose | Example |
|---|---|---|
| Base Policy | Applies to every runtime decision. | Log all tool calls, block obvious secret exfiltration, warn on sensitive reads. |
| Policy Profile | Adds audience-specific controls. | Contractors cannot use WebFetch. Finance cannot write outside approved repos. |
| Detector response | Controls what happens when a detection matches. | Prompt injection Blocks for production engineers, Warns for security researchers. |
| Evidence | Explains why the decision happened. | Source, user, group, tool, target, detector, reason. |
When to create a Policy Profile
Create a Policy Profile when one of these is true:
- A synced group needs stricter controls than Base Policy.
- A pilot cohort is testing a new rule before broad rollout.
- A contractor or vendor audience needs reduced capabilities.
- A sensitive team needs additional evidence retention.
- A development workflow needs a temporary exception that should remain visible.
Do not create a profile just to rename Base Policy. If everyone needs the rule, put it in Base Policy.
Assignment flow
- Confirm the user or group exists in People or Directory Sync.
- Create the Policy Profile.
- Add the runtime controls that differ from Base Policy.
- Assign the profile to the group.
- Run a clean activity test and a documented Block test as a user in that group.
- Confirm Activity shows the expected source, person, group, and policy reason.
Users and groups
Policy Profiles work best with authoritative groups:
- Use Directory Sync for durable Entra ID, Okta, or Google Workspace groups.
- Use custom groups for pilots, exceptions, and temporary cohorts.
- Avoid hidden exceptions that only exist in a profile description.
- Review group membership before moving a profile from pilot to production.
Troubleshooting Policy Profile assignment
| Symptom | Likely cause | Fix |
|---|---|---|
| User signs in but no group profile applies | SSO is working, but Directory Sync has not supplied group membership. | Configure Directory Sync or add the user to a custom group. |
| Group exists but runtime event uses Base Policy only | The runtime event did not resolve to the expected person or group. | Check People, workstation ownership, and group membership. |
| Policy Profile blocks too much | The audience is too broad or the rule belongs in a narrower profile. | Split the group or move the rule to a smaller pilot profile. |
| Admin cannot find a group | The group was not synced or is filtered out by provider configuration. | Check Directory Sync status and provider assignment. |
Enterprise acceptance checks
Before calling Policy Profiles production-ready:
- A synced or custom group is visible in AgentKeeper.
- The group has the expected users.
- The Policy Profile is assigned to that group.
- A benign action still passes for the group.
- A documented Block test blocks for the group.
- Activity explains the policy reason without requiring support to inspect the database.