Explainer
Choose rules, guards, or quotas for the job
“Put a guardrail on it” leaves an operator with an unfinished requirement. Does the team need to refuse an action, change the content crossing a connection, or limit consumption?
Dome separates those jobs into rules, guards, and quotas. Start by saying what must not happen: an export, an exposed email address, or another call after the budget runs out.
Translate the requirement into a control
| Requirement | Primary control | Acceptance test |
|---|---|---|
| This agent must not call the export operation | Authorization rule | The export is refused while an approved read still works |
| This request must carry a verified represented user | Identity configuration and claim-aware rules | Missing or invalid identity cannot become accepted authority |
| A returned contact field must not reach the agent | Response guard filter | The returned fixture is redacted or omitted as intended |
| A tool request must include a required structural field | Request guard validator | Missing required structure blocks the request |
| This workload has a defined token/call/cost allowance | Applicable quota | Exhaustion produces the expected refusal at the intended scope |
| A ticket must belong to the user's account | An authoritative resource check, used by the deciding component | A misleading caller-supplied account label cannot substitute for the real relationship |
For the last row, check the ticket system's records. A request that says “this ticket belongs to North” doesn't prove that it does.
Follow a ticket read through the checks
Consider an illustrative support agent asking for a ticket summary. Its operation is permitted, but the source record includes the customer's private contact details. The workload also operates within an agreed usage allowance.
The agent may be allowed to read the ticket without needing every field in it. A rule can permit the intended operation without authorizing every field to reach the caller. A response filter can remove or redact protected fields without changing which agent was authorized to call. A relevant quota can govern consumption even when both the operation and content handling are acceptable.
Record the three expectations separately:
| Test fixture | Authority expectation | Content/consumption expectation |
|---|---|---|
| Allowed ticket read containing protected contact fields | Permit the intended call | Protected fields do not reach the agent in clear text |
| Forbidden export with harmless-looking content | Deny the operation | Harmless content does not reopen forbidden authority |
| Allowed read missing a required structural request field | Permission alone doesn't make the request valid | Configured request validation blocks the malformed request |
| Otherwise valid work after the applicable allowance is exhausted | A permit is not extra budget | The relevant consumption control refuses affected work |
These are illustrative acceptance cases. They are not a promise that every quota dimension applies to every resource or that a response block reverses a backend action. Use the supported scopes and the actual point of enforcement.
Specify where the decision happens
Rules decide which calls are permitted. Guards inspect content on a connection, in the request or response direction. Quotas limit supported usage at a configured scope. For the ticket-read example, check the tool or tool-connection quota; a model-pool budget does not limit that tool call.
Request and response guards answer different questions. A response filter acts before inspected content reaches the agent, but the upstream may already have performed the operation. If the concern is whether a write should happen at all, put the necessary authority and request checks before dispatch.
Do not create a single “safe” checkbox that hides those differences. A review should show which test proved each requirement.
Keep a separate test for each requirement
In Dome, the same identified agent can be subject to all three controls. Keep the test results separate so you can tell whether a refusal came from permission, content inspection, or the applicable allowance.
For more detail, see content filtering vs. schema validation, action authorization, and spend governance.
Keep the requirement-to-control table with the integration. When a stakeholder asks for a new guardrail, add a concrete requirement, a responsible owner, and a test that can fail.