Testing a Policy Before You Deploy It

You don't have to find out whether a policy works by letting your agent run into it. Gatekeeper can simulate a decision without touching the connected service — nothing is called, nothing is changed, and no audit record is written.

This is the fastest way to answer "will this be blocked?" before it matters.

Simulating a decision

Ask Gatekeeper to evaluate a hypothetical request: name the service, the tool, and the parameters you expect your agent to send. You'll get back:

  • The outcome — allow, deny, or require approval
  • Which chain decided, and the name of the specific rule that fired
  • The full verdict trail — every chain that was consulted and what each returned

That verdict trail is the useful part. If a policy isn't behaving the way you expect, it's usually because an earlier chain decided the request before your rule was reached. The trail shows you exactly where the decision was made.

Example output for a HubSpot contact creation:


action:     allow
chain:      svc-hubspot
rule:       svc-default
trail:      default → pass
            svc-hubspot → allow

Inspecting the context object

Before writing a rule that depends on a particular field, check what's actually in the request. Gatekeeper can return the raw context object it would hand to your policy — the exact field names and values available for that specific call.

Write your rule against what you see there, not what you assume is present. Field availability varies between services, and a rule referencing a field that's empty or absent will silently never match.

A safe workflow for policy changes

  1. Inspect the context for the request you want to govern, so you know which fields you can rely on.
  2. Write the rule.
  3. Simulate the request you want blocked. Confirm it's denied, and confirm the rule that fired is yours.
  4. Simulate a request you want allowed. This is the step people skip, and it's how over-broad rules get shipped — you confirmed the block worked, but not that everything else still does.
  5. Check the verdict trail to be sure your rule decided the outcome, rather than a coincidentally-agreeing rule in another chain.
  6. Deploy, then verify against real traffic in the audit log.

Simulating as another user

You can also run a simulation as though a different person made the request. This is how you check user-level and per-user-service rules without needing that person to trigger the action themselves — useful for confirming that a restricted role really is restricted.

Note that credential details show as empty when simulating as someone other than yourself. The policy decision is still evaluated; only the credential fields are withheld.

What simulation will not tell you

  • Whether the tool name is real. Simulation deliberately doesn't contact the service, so it can't validate that a tool exists. A typo in a tool name will simulate cleanly and then fail for real.
  • Whether the call would actually succeed. Simulation returns the policy decision, not the service's response. An allowed action can still fail on the service's own validation or permissions.
  • Whether the service is connected. Simulating against a service your organisation hasn't connected returns an error rather than a decision, since a verdict about an unreachable service would be misleading.

Related Articles