Loading page
About this tool
Build a local JSON allow-and-deny policy for agent tool names, paths, domains, recipients, numeric limits, and confirmation flags.
The Agent Permission Policy Builder turns plain lists into a validated JSON permission policy for an AI agent, covering seven rule groups: allowed tools, denied tools, allowed filesystem path prefixes, allowed domains, allowed message recipients, named numeric ceilings, and which tools require a confirmation flag before they run. It validates as you type — hostnames are parsed properly so a URL with a path or port is rejected, numeric limits must be non-negative numbers, and requiring confirmation without naming an accepted flag is treated as an error rather than a silent gap. It is for developers and platform owners writing the guardrail file itself; the document is generated in your browser and enforces nothing on its own.
Open Agent Permission Policy Builder on AltFTool — it loads instantly in your browser.
Under Tool names, list Allowed tool patterns and Denied tool patterns one per line or comma-separated, up to 200 entries of 500 characters each.
Under Targets add Allowed path prefixes, Allowed domains as bare hostnames such as example.com or *.example.com, and Allowed recipients; under Limits and confirmation add Numeric ceilings in the form field = maximum, plus Tools requiring confirmation and the Accepted confirmation flags.
Clear the errors and warnings shown above the Policy JSON pane — colliding allow/deny patterns, relative path prefixes, confirmation with no accepted flag — then press Copy JSON, or Download to save agent-permission-policy.json.
Domain entries are parsed as hostnames and rejected if they carry a path, port or whitespace, so an entry like example.com/api never silently becomes a rule that matches nothing.
Overlapping allow and deny entries raise a warning that says deny wins, relative path prefixes are flagged as ambiguous, and a policy with no enforceable rule at all is called out.
If any tool is marked as needing confirmation, the builder refuses to produce a policy until you list the flag values that count as confirmation.
A single JSON object with allowedTools, deniedTools, allowedPathPrefixes, allowedDomains, allowedRecipients, numericLimits and a confirmation block holding requiredForTools and acceptedFlags. Each list accepts up to 200 entries of up to 500 characters, split on newlines or commas and deduplicated case-insensitively.
Deny wins, and the builder raises a warning naming how many patterns collide. Deny-by-default is the safer resolution, but a rule sitting in both lists usually means two people edited the policy with different intentions, so it is worth resolving rather than leaving.
Domains are hostnames only — example.com, or *.example.com to include subdomains — with no scheme, path or port. Numeric limits are one per line in the form 'field = maximum' or 'field: maximum', such as max_transfer_amount = 5000, and the value must be a finite non-negative number; if the same field appears twice, the last value is used and you are told.
No. It is a configuration document, and it constrains only the checks that your linter, runtime or agent framework actually reads and enforces. Generating a policy is the first step; wiring it into the execution path, and testing that a denied call is genuinely refused, is the step that provides the protection.