Validate a simulated agent permission boundary
Check a tool allowlist and observable decisions using benign local requests.
Audience: practitioners reviewing agent tools and application logs. Prerequisites: basic JSON and Python 3.9 or later, with no additional packages. Planning time: 15–20 minutes. Executed here with Python 3.13.12 on Linux; fixture and policy version 1.0, reviewed 2026-09-09.
This simulator accepts only an exact read request for reports/summary.txt. Every other request is denied. It evaluates request objects without performing their operations; no network, secrets, paid service, or privileged action is involved. Retrieved document text cannot change the fixed policy.
Permission and observation boundary
The authored fixture includes one permitted read, a secret-path read, traversal, a write, a proposed transfer to a reserved example domain, and a missing operation. The expected field is the test oracle; it never authorizes an operation. Events record request ID, decision, policy version, and operation_executed: false. Their ordered IDs must match the submitted requests exactly.
Download and run
- Save requests.json and validate.py in an empty working directory.
- Read the allowlist, fixture expectations, and verifier before running. Confirm that no requested tool is invoked.
- Run the commands below. The second prints the individual observable events after the summary.
python3 validate.py requests.json
python3 validate.py requests.json --eventsExpected output and negative controls
{"allowed_ids": ["read-report"], "denied": 5, "events_observed": 6, "negative_controls_rejected": 2}The two additional controls deliberately remove the final event and change all decisions to allow. The verifier must reject both. The traversal and missing-operation fixtures separately exercise fail-closed decisions. Change a fixture's expected secret read to allow: validation must fail with Permission or observation boundary mismatch. Duplicate request IDs must also fail. Missing files and malformed JSON stop with a Python error.
Visibility limits and conclusion
A passing run demonstrates only this exact policy function and event checker. It does not test an LLM, operating-system sandbox, credentials, approval service, tamper-resistant logging, or enforcement in a real agent. Since every event is generated locally by the same simulator, event completeness is a fixture invariant rather than independent proof that a production tool was blocked. Avoid prefix-based authorization without a separate canonical-resource design and threat review.
Next step: follow the AI/agent security path. In an authorized integration, record which component enforces permissions and which independent observation proves whether a tool actually ran. Include an event-loss test before relying on the log.
References
- OWASP: Agentic AI threats and mitigations — architecture context; this small simulator is an authored exercise, not an OWASP conformance test.
- Python: JSON encoder and decoder.
- 1200km: AI security.