See how Qpoint secures the hidden agent surface.Read the blog post →

Policy demo
Write a Qpoint policy from scratch

Some agent risks are easy to predict, like a git force push that rewrites a shared branch. Others are harder to predict, like an agent finding a new way to send data off the machine. A single Qpoint policy can cover both. In this demo, we write a policy from scratch. We start with simple rules that block force pushes and limit agents to an approved list of MCP servers. Then we add a rule that has an AI judge review each command and flag any that send sensitive data to an outside server.
Gaurav Mahajan
Gaurav Mahajan
November 10, 2026

About this demo

In this demo, we build a Qpoint policy file step by step and explain each part as we go.

First, we configure the judge, a fast decision model that any rule can call. We then write static rules to control for known risks. One rule denies git force pushes. Another denies reads of .env files. A third uses a custom list of approved MCP servers and denies calls to any server that is not on the list. A denial message is configured, so the agent can inform the user why the call was blocked and who to ask for access.

Static rules cover the risks that you can anticipate. Since an agent can send data off the machine using many different commands including curl, scp, and netcat, we add an intent-based rule that asks the judge whether a command sends secrets, customer data, or private files to an outside server. To start, the rule flags these commands in the audit log but doesn’t block them. If the security team sees the same command come up repeatedly, they can write a static rule to block it, or switch the rule from flag to deny.

Every rule has the same three parts: a title, a condition, and an action. The same structure works for file writes, skill loading, HTTP requests, and prompts sent to the model. Any of these rules can be static or use the judge.

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