AI Agent Governance

InPolicy’s AI Agent Governance extends the policies you already author in InPolicy into every AI conversation your team has. Same policies, two use cases, two audiences:

Use case	For	How to set it up
Employees using Claude Desktop / Claude Code / Cursor	IT	Deploy the MCP server + a company system prompt
AI agents you build in-house (customer service, internal tools)	Developers	API Quickstart → SDK → LangChain

A note on terminology

“Agent” is overloaded in this space. In these docs, “AI agent” / “the agent” always means the AI software (the LLM-powered system making calls into InPolicy). When we mean a human customer-service rep, we say “rep” or “support rep” to keep the two distinct.

What “agent governance” means here

Your policies already live in InPolicy. The browser extension catches violations when a human types in a browser, and the Mac app catches them across native macOS apps. Agent governance is the third surface: it catches violations when an AI agent is drafting, responding, or taking action.

There are two moments per AI inference where we can intervene:

1. Before the model generates. We inject the relevant policies into the system prompt so the model actually knows what it has to follow.
2. After the model generates (optional). We check the output against policies and surface violations, with a suggested compliant rewrite when possible.

You can also gate tool calls. If an agent is about to send an email or trigger an action that would violate a policy, we can block it.

What this is not

• Not a filter on top of ChatGPT/Claude. It’s integrated into the agent via the Model Context Protocol or our REST API. The agent itself asks InPolicy for applicable policies; we don’t intercept network traffic.
• Not 100% coverage. The agent has to actually call InPolicy on each turn. With good system prompts, compliance is high but not perfect. Treat it like a safety belt, not a cage.

What policies drive agent behavior

The same ones you’ve already authored. If you have a policy that says “Don’t share customer PII in external communications,” the agent sees that policy every time it’s about to draft a message and follows it.

No separate “AI policies” corpus. One source of truth.

How a conversation looks to InPolicy

The agent tells us, in real time:

• “User just said X.” We pull the policies that apply given the full conversation so far and hand back a short block of text for the agent’s system prompt. This is the primary mechanism.
• “I’m about to respond with Y.” Optional. When enabled, we review the output and surface any violations with suggested rewrites.
• “I’m about to call the send_email tool with these arguments.” Optional. When enabled, we check the proposed action against policies and either allow or block.

We never store the conversation content itself. See Privacy & data handling for the full story.

Two surfaces, one engine

	MCP server	REST API
Primary audience	IT deploying Claude Desktop/Code/Cursor for employees	Developers building custom agents
Install	npx @inpolicy/mcp-server	npm install @inpolicy/sdk
Guarantees	Best-effort. The model decides when to call InPolicy, guided by a system prompt	Reliable. Your code calls InPolicy on every turn
Data handling	Identical. No conversation content stored	Identical

For employee-facing deployments, the MCP server is the right answer: IT sets it up once, users type normally, and the system prompt steers the agent toward following the policies. For production AI products you build yourself, the REST API + SDK is what you integrate.

Developers can use MCP too. The Anthropic API supports MCP servers natively, and any agent you build with the Anthropic SDK, LangChain, or a custom framework can connect to the InPolicy MCP server. MCP is a good fit when:

• You’re prototyping. Spin it up in Claude Code or Cursor and iterate.
• Your agent is built on an MCP-aware runtime (Anthropic API with mcp_servers, Claude Code agents, etc.).
• You want the model to decide when governance applies, rather than calling it on every turn deterministically.

Use the REST API + SDK when:

• You want guaranteed coverage. Your code calls record_turn on every turn, not the model.
• Your agent framework doesn’t support MCP (most LangChain chains, custom orchestrators).
• You need tight control over latency, retry, or error handling.

Both surfaces talk to the same engine, store the same amount of state (none of the conversation content), and carry the same guarantees.

Next steps

• If you’re IT, deploying for employees: start with Claude Desktop setup.
• If you’re building an agent: start with the API Quickstart.
• If you want the concepts first: read Core concepts.