Policy harness
Before a request reaches a model, the policy harness decides whether it should, based on who is asking, what they are asking for, and what data is involved.
- Policy harness
- Model routing harness
- Data transfer harness
- Guardrails harness
- Security harness
- Evaluation harness
- Observability harness
- Cost and token harness
- Reliability harness
- Audit harness
What it controls
The policy harness sits in front of every model call and checks it against rules your organization sets: which users or services may use which models, which data categories each model is allowed to see, and which actions require a human in the loop.
It is the single place those rules live, instead of being scattered across application code, prompts, or individual engineers' habits.
Why it matters
Without a policy layer, access decisions happen implicitly: whoever has an API key can call whatever model they want with whatever data they have on hand. That is not a model problem. The model answers exactly what it is asked; the gap is that nothing decided in advance whether it should have been asked.
When access rules live in policy instead of in scattered code, they can be reviewed, audited, and changed in one place, by the people responsible for compliance and risk, not by whoever last touched the integration.
What good looks like
Look for a policy layer that can answer these questions, consistently, for every request:
- Who is this request from, and are they allowed to make it
- Which model is this going to, and is that model approved for this data
- Does this combination of user, data, and model need a human approval step first
- Is the rule enforced before the call, not just logged after it
- Can the rule be changed without redeploying application code
How it works with the other harnesses
Policy sets the rule; model routing acts on it by sending the request to a model that is actually allowed to see that data; data transfer carries the data under the same rule; audit records that the rule was followed. None of the other harnesses can compensate for a missing policy layer, because they all depend on policy having already decided what is permitted.
In practice
Real patterns on the Resources page that lean on this harness:
- AI-driven connector builder with human approval
- Multilingual HR document processing with compliance tracking
Frequently asked questions
Does a policy harness slow down requests?
The check happens inline, before the model call, not as a separate review step for every request — most traffic passes through instantly because it matches an existing rule. Only requests that fall outside the rules need a human decision.
Is this the same as role-based access control (RBAC)?
RBAC is one input to it. Policy also accounts for which data the request touches and which model it is going to, not just who the user is.
Who sets the rules?
Whoever owns the risk: typically a mix of platform, security, and compliance teams, not individual engineers choosing per integration.
What happens when a request doesn't fit any rule?
It should be blocked by default, not allowed by default, with a clear path to request an exception.
Questions about your AI rollout?
Talk to us about which harnesses fit your models and data.