Create AI-Agent Permission Boundaries

#CONTEXT:
Create a least-privilege permission-boundary proposal for one bounded AI-agent job. This is review support for named human owners, not authorization or a request to change access.

#INPUTS:
- Agent job, trigger, inputs, decisions, outputs, completion, non-goals, fallback, and environment: [AGENT JOB]
- Allowed actions, prohibited actions, and actions requiring named-human approval: [ALLOWED AND PROHIBITED ACTIONS]
- Approved systems, resources, environments, integrations, system owners, and available scopes: [SYSTEMS]
- Named credential owners, agent identities, secret-manager references, rotation owners, and current review state: [CREDENTIAL OWNERS]
- Approved data classes, purpose, source authority, sensitivity, retention, residency, and prohibited destinations: [DATA CLASSES]
- Explicit approval gates for read, draft, write, send, transact, modify, delete, administer, connect, production, and exception authority: [APPROVAL GATES]
- Required identity, action, source, result, approval, correlation, review cadence, and access-review evidence: [LOGGING AND REVIEW REQUIREMENTS]
- Supplied revocation owner, emergency stop, offboarding, incident evidence, fallback, reconciliation, and restart rules: [REVOCATION AND INCIDENT RULES]

#INSTRUCTIONS:
1. Map each requested capability to a supplied job requirement and evidence or source attribution. Label missing facts Unknown and incompatible access rules Conflict—human resolution required.
2. Use least privilege. Begin with no access, then propose only the minimum resource, environment, action, scope, data class, purpose, duration, and evidence needed for the bounded job.
3. Separate each capability as Required for review, Approval-gated, Prohibited, Not needed, or Unknown. A technical capability is not a business requirement or authorization.
4. Prefer read-only and draft-only access where it satisfies the job. Treat write, send, transaction, modification, deletion, administration, credential, cross-customer, sensitive-data, and production access as separate capabilities.
5. For every proposed capability, state the named human system owner, credential owner, data owner, approver, review cadence, logging evidence, stop condition, and revocation path. Missing ownership or evidence must fail closed.
6. Preserve credential secrecy. Record only identity name, credential owner, secret-manager reference, scopes, rotation state, and review evidence. Never request or reproduce a secret value.
7. Separate design status as Proposed, Approved, Provisioned, Validated, Active, Revoked, or Unknown. Separate verification status as Planned—not executed, Executed—not yet reviewed, Passed—evidence reviewed, Failed, Blocked, or Unknown. Never claim access or monitoring is active without supplied evidence.
8. Do not invent, infer, or fabricate an SLA, threshold, result, scope, permission, credential state, owner, data classification, approval, validation status, monitoring state, or system capability. Unsupported values remain Unknown.
9. Fail closed on missing job justification, source authority, data purpose, owner, approval gate, logging, revocation, environment, permission evidence, or unresolved conflict.
10. Do not infer authorization from a capability list, credential owner, existing scope, integration feature, prior approval, or test result.
11. Do not grant, revoke, or change permissions. Do not provision an agent or service account with access, permissions, or a role. Do not use or reveal credentials. Do not rotate any credential, token, API key, or secret. Do not deploy, enable, or disable an agent. Do not restart, pause, or activate an agent. Do not connect an agent or integration to a live system. Do not execute transactions. Do not send externally. Do not change production or claim monitoring is active.
12. Address privacy, security, data classes, purpose limitation, segregation, retention, and minimization. Use only authorized company data in an approved AI workspace or approved AI vendor. Minimize inputs and redact or omit unnecessary personal, sensitive, or confidential data. Follow company retention and vendor policy.
13. Never paste secrets, credentials, tokens, API keys, private keys, or recovery codes.

#RESPONSE FORMAT:
## Job-to-access evidence and source attribution
| Job requirement | Evidence source | Required capability | Owner | Conflict or Unknown |
|---|---|---|---|---|

## Least-privilege permission boundary
| System and environment | Resource and data class | Action and scope | Required, approval-gated, prohibited, not needed, or Unknown | Purpose | Named owners and approver | Logging evidence | Stop and revocation conditions |
|---|---|---|---|---|---|---|---|

## Credential reference and review register
| Identity name | Credential owner | Secret-manager reference | Scope | Rotation state | Verification: Planned, Executed, Passed, Failed, Blocked, or Unknown |
|---|---|---|---|---|---|

## Fail-closed gaps, conflicts, and Unknowns

## Approval-gate and validation register