Policies

Kontext checks policies before an agent runs a tool call. Workspace owners and admins manage them in Authorization → Policies. Everyone else sees “Only organization admins can manage authorization.”

​

What a policy checks

Kontext converts each tool call into a request with the endpoint, agent, tool, tool input, and session. For shell commands, Kontext includes the parsed program and recognized operations, such as a force push. You scope each policy to agents and endpoints when you add it.

​

How policies combine

Policies use Cedar permit and forbid rules. Kontext denies a call if a forbid matches. Otherwise, a matching permit allows the call. Calls that match no rule receive Deny. Kontext adds Allow tool use unless blocked, which permits every tool call. Each preset adds a forbid for one kind of operation. With this baseline, the status under the page heading reads “Everything these policies do not block is allowed.” For example, with only Block GitHub force pushes added:

​

Enforced and Observing

A policy in the Enforced list blocks matching calls. A policy in the Observing list shows how many calls it would have blocked without blocking them. Every new policy starts in Observing. Check its matches, then click Enforce to move it to Enforced. See Add a policy. The workspace has one mode for all endpoints: Kontext saves and deploys each action on the page immediately. Endpoints apply changes on their next check-in, about once a minute. See Rollout and failure behavior for endpoint behavior during updates and failed checks.

​

Limits

Kontext checks the tool call at the agent’s hook, before the tool runs. Policies cannot inspect a running script’s actions or code that an interpreter such as Python executes. These checks cover only agents with Kontext hooks on the endpoint. You can review Risk findings, but they do not change decisions.