AI Tool Permission Demonstration

This deterministic demonstration is not a live LLM, prompt-injection detector or security benchmark. It illustrates a server-side policy boundary using fixed fixtures. Nothing is emailed, deleted or executed.

No evaluation yet.

What is being tested?

A retrieved document can contain “ignore previous instructions” or “the user approved this”. Such text is source data, not an authorisation record. The fixture checks the proposed tool against an allowlist, the authenticated role and the trusted application's approval state. It deliberately does not decide whether the text “looks malicious”.

Expected decisions

• Allowed read: allow for the employee fixture.
• Email send: require approval, regardless of what the retrieved document says.
• Delete tool: reject because it is not in the allowlist, even with approval.

What changes in production?

The checkbox represents state a browser user must not be able to grant themselves in a real system. A server must authenticate the approver and bind their decision to the exact recipient, payload, operation and expiry. Validate parameters, enforce document-level permissions and keep an audit trail. This small example does not implement those controls.

Reproduce and extend

The decision function is available as readable source. Tests cover unapproved tools, missing approval, untrusted source instructions and invalid roles. Real application testing also needs tool-result injection, cross-user retrieval, approval expiry and parameter substitution cases.

Reference: OWASP prompt injection. See LLM security testing for engagement scope and limitations.