# Agent Permission Boundary Designer

Translate an agent's responsibilities into least-privilege tool permissions, scoped credentials, approval rules, and revocation controls.

## Prompt

You are an AI security architect who specializes in least-privilege access for autonomous agents.

Inputs:
1. Agent responsibilities and prohibited outcomes: {{responsibilities}}
2. Systems, tools, and data involved: {{systems_and_data}}
3. Required read, write, execute, and communication actions: {{required_actions}}
4. Identity, authentication, and approval options: {{security_options}}
5. Compliance, audit, and operational constraints: {{constraints}}

Do the following:
1. Map each responsibility to the minimum data objects, operations, environments, and time windows required; flag permissions that are convenient but not necessary.
2. Design permission tiers for routine, elevated, and emergency actions, including scoped credentials, just-in-time access, approval, rate limits, and transaction limits.
3. Define controls against confused-deputy behavior, indirect prompt injection, cross-user data leakage, credential exposure, and unauthorized tool chaining.
4. Specify denial behavior, escalation, credential rotation, revocation, break-glass access, and immutable audit events.
5. Output a permission matrix, trust-boundary diagram in text, sample policy rules, abuse-case tests, and a rollout sequence that starts with the safest viable scope.

## Best for

Security and platform teams granting agents enough access to work while minimizing the damage from mistakes or manipulation.

## Compatible tools

- Claude
- ChatGPT

## How to use

- List actions at the API-operation level where possible.
- Separate required permissions from convenient access.
- State monetary, temporal, and volume limits.
- Have security owners review the resulting permission matrix.

## Customization tips

- Add tenant, record, and field-level data scopes.
- Use short-lived credentials instead of broad permanent tokens.
- Define a safe read-only degradation mode.
- Include real abuse cases from threat modeling.

## Example input

Responsibilities: Resolve tier-1 ecommerce support requests, issue refunds under EUR 75, and update shipping addresses before dispatch; never view full card data or cancel fulfilled orders. Systems: help desk, order database, shipping portal, and payment processor. Actions: read customer and order records, draft replies, change unshipped addresses, and issue limited refunds. Security options: service identities, OAuth scopes, approval queue, and per-action logs. Constraints: GDPR, 24/7 operation, 30 refunds per hour maximum, and immediate revocation by an on-call engineer.

## Example output

The matrix grants order.read only for the active ticket's customer, shipping.address.write only before the dispatch flag, and refund.create with a EUR 75 per-transaction and 30-per-hour cap. The payment processor returns masked instruments only. Refunds above EUR 75 require a time-limited elevated token approved by a supervisor. Tool outputs are treated as untrusted content, and no retrieved text can request broader scopes. The design includes denial messages, revocation events, and abuse tests for cross-customer access and chained refund attempts.