Your agents need a dynamic sandbox.Read the blog post →

Policy demo
Enforce an agent’s purpose

An agent often needs permission to use a tool, but not for everything that tool can do. A pull request review agent needs to post comments, for example, but it shouldn’t approve the PR on behalf of the team. Qpoint uses a System One model to check each action against the purpose you define for the agent, so the review comments go through and the approval is blocked, even when the project’s instructions tell the agent to approve it.
Gaurav Mahajan
Gaurav Mahajan
November 5, 2026

About this demo

Permission to use a tool is usually all or nothing. An agent that reviews pull requests needs permission to comment, but you probably don’t want it approving PRs on behalf of the team. In this demo, we define the agent’s purpose in a Qpoint policy: read the code, run the tests, and comment with findings, while the decision to merge stays with a human. A judge model checks every shell command and MCP call against that purpose.

The project’s AGENTS.md tells the agent to post “approved on behalf of the team” as its last step. Claude Code posts its review comments normally, but the approval comment is blocked, even though it uses the same tool. Instructions in the project can’t override the policy, so IT or security can set it centrally while developers keep their own workflows and agents.

Then we change the purpose while the session is running, so findings stay in local chat instead of going to GitHub. The same review comment that was allowed earlier is now denied, with no restart.

See Qpoint in action in your environment
Request access and we'll get you set up.
Request Access