Runtime Policies

How policies are defined

Policies are written declaratively, as code: rules like "block access to production databases for agents in development status" or "throttle token usage to 10,000 per hour for team X" read close to how a team would describe the rule out loud. Because policies are code, they live in version control alongside the agents they govern, and can be reviewed the same way any other change is reviewed before it ships.

The same registry identity used for cost attribution and quality scoring is what a policy matches against: an agent's owner, team, framework, and permissions are already known, so a rule doesn't need to redefine what it means for an agent to belong to "team X".

How enforcement works at runtime

The policy engine sits at the point where an agent calls a tool, queries an API, or touches data: the same interception point across every framework Prefactor integrates with. Every attempted action is evaluated against the agent's identity, its permissions, the data involved (including any data tags it carries), and the current context (time of day, rate limits, the agent's current risk category) before it's allowed to proceed.

Evaluation runs in sub-millisecond time, so enforcement doesn't add meaningful latency to the agent's response. The result is one of allow, block, throttle, sandbox, or escalate to a human reviewer: the same action set risk monitoring can trigger automatically when an agent's risk crosses a threshold.

Observation mode and safe rollout

New policies can run in observation mode first, logging what the policy would have blocked or throttled without actually enforcing it. That gives a team a way to see how a rule behaves against real traffic before it can affect a production agent, and to catch a policy that's too broad before it starts blocking legitimate actions.

Once a policy's observed behaviour matches what the team intended, switching it from observation to enforcement is a configuration change, no redeployment of the agent required. The same no-redeploy mechanism is what makes the kill switch instant.

Policy management and versioning

Policies move through the same draft, review, active, and archived lifecycle as code: a new policy is authored, reviewed, tested in observation mode, and only then made active. Because policies are declarative and version-controlled, an active policy can be rolled back the same way a bad code deploy would be, without touching the agents it applies to.