The architecture is the same whoever supplies it. Applications send their requests to AI models through a single control point. The rules live at that point, every request crosses it, and no application has to carry its own copy.
Four things become possible at that point
| Capability | What happens | What it answers |
|---|---|---|
| Inspection | Every request and response that crosses the enforcement point is seen before it continues. | What was sent, and what came back |
| Enforcement | A rule that would be violated is acted on while the request is in flight: the response blocked, the sensitive portion removed, or the request refused. | Whether the rule held |
| Observation | Usage, cost, and rule triggers are visible to the organization while they happen. | What you can see while it runs |
| Attribution | Every interaction is tied to an identified person or agent. | Who did what, afterwards |
Products that provide this control point are sold as AI gateways or LLM gateways. Sentinel is one example. Sentinel replaces email addresses, phone numbers, Social Security numbers, credit card numbers, IBANs, IP and MAC addresses, and API keys, cloud credentials, and tokens in known formats. Bank account numbers, driver's licenses, tax IDs and EINs, national IDs, VINs, dates of birth, and medical record numbers are replaced when a label sits next to them, such as "Account number:" or "MRN:". It does not catch names, street addresses, passport numbers, bank routing numbers, unlabeled numbers, or values under a column header in a pasted table.
Each depends on the one before it. Nothing can be enforced on traffic that was never inspected. Direct-to-vendor use and separate product surfaces can bypass a gateway, so the claim applies only to covered traffic. A log of rule triggers says little if it cannot name whose request tripped them.
Rules become configuration
Because the control point is separate from the applications, a rule applied there is a setting. Changing it is one edit in one place, and it takes effect for every application at once, including tools adopted after the rule was written. The applications never need to know the rule exists.
That property does most of the practical work. A new category of data to protect, a model that is no longer approved, a team that needs a stricter rule set: each is a configuration change, reviewed and recorded like any other. When rules differ between deployments, as they do across regulatory regimes, the difference is a second rule set running on the same machinery.
What to ask of any implementation
- Coverage. Which AI traffic actually passes the point? Traffic routed around it is ungoverned, and a control point that sees half the requests enforces half the rules.
- Timing. Is the rule applied before the response reaches the person, or reported afterwards? Only the first is enforcement.
- Ownership of the record. Can your own people open the log, query it, and export it without asking the supplier?
Use the side-by-side Sentinel comparisons to check coverage, records, deployment, and documented limits across products.
A control point has limits too, and they are worth knowing before you choose one. It can bound what a system does and record what it did. It cannot make a model's judgment correct. Those limits are set out in what a governance layer cannot do.
Frequently asked questions
- What is AI enforcement at runtime?
- It is one point that every AI request passes through on its way to a model, where rules are applied before a response reaches anyone. Applications send their requests through that single control point, the rules live there, and no application has to carry its own copy. Inspection, enforcement, observation, and attribution become possible at that point.
- What are the four capabilities of a runtime control point?
- Inspection sees every request and response before it continues. Enforcement acts on a rule violation while the request is in flight, by blocking the response, removing the sensitive portion, or refusing the request. Observation shows usage, cost, and rule triggers as they happen. Attribution ties every interaction to an identified person or agent.
- Why are AI rules configuration at a control point?
- Because the control point is separate from the applications, a rule applied there is a setting. Changing it is one edit in one place, and it takes effect for every application at once, including tools adopted after the rule was written. A new data category, an unapproved model, or a stricter rule set is each a configuration change.
- What should you ask of any runtime enforcement implementation?
- Ask about coverage: which AI traffic passes the point, since traffic routed around it is ungoverned. Ask about timing: whether the rule is applied before the response reaches the person or reported afterwards. Ask about ownership of the record: whether your own people can open, query, and export the log without asking the supplier.
- Does a control point make a model's judgment correct?
- No. A control point can bound what a system does and record what it did. It cannot make a model's judgment correct. Direct-to-vendor use and separate product surfaces can also bypass a gateway, so the claim applies only to covered traffic. A log of rule triggers says little if it cannot name whose request tripped them.