Test the blocked path
Use synthetic examples of risky commands, protected files, common credential patterns and unapproved destinations. Check the decision and the evidence recorded for it.
Validation approach
Test the behaviour you need to rely on.
A configuration file states intent. Validation checks whether the selected controls behave as expected in the environment where people will use them.
Test legitimate work
Check expected read-only activity and actions requiring human approval. A useful baseline needs predictable behaviour for developers as well as coverage of risky actions.
Test the deployed configuration
Hook tests are one layer. Verify managed settings, sandbox behaviour, identity restrictions and network controls on the selected endpoints, with evidence from the responsible systems.
Retest after change
Repeat the relevant tests after agent, model or configuration changes. Compare outcomes, investigate regressions and record the decision before extending rollout.
Example: a protected credential path
Start with a synthetic request to read a protected credential path. Confirm that the configured hook denies the request, explains the control and produces an evidence record. Then test the relevant sandbox boundary separately; a hook result alone does not establish coverage of every subprocess.
Make results reviewable
Keep the test input, expected outcome, actual outcome and configuration version together. Use synthetic data and review evidence handling. Passing a finite test suite supports a decision about the tested scenarios; it cannot establish that all possible bypasses have been eliminated.
This page describes our validation approach. It is not a customer case study, independent benchmark or claim of universal protection.