Enterprise Agent Security Checklist: Tool Permissions and Human Approvals

A valid token does not make an agent's next action safe. Enterprise teams need to control what an agent can do, which actions need approval, and how execution is observed and stopped. Secure the execution path, not just the conversation.

This checklist develops themes from a Reddit discussion on internal enterprise agents: per-agent tool scopes, destructive-action approvals, audit events and runtime monitoring. Our November 12 review found the original post deleted; the discussion is qualitative context, not a security standard or evidence of enterprise adoption. The implementation recommendations below are an editorial synthesis, not quotations or an endorsement of products in the thread.

1. Define the agent's authority before connecting tools

Record the workflow, data classifications, accountable owner and maximum acceptable impact. Separate recommendations from execution. A customer-support agent that reads tickets should not inherit permission to export every customer record.

• Assign each agent a distinct workload identity and owner; avoid shared employee credentials.
• Allow only required tools, operations and resource scopes; default-deny everything else outside the model.
• Use short-lived, task-scoped credentials; isolate development, testing and production identities.
• Document prohibited actions, sensitive datasets and a review date for every permission grant.

2. Make approvals specific, enforceable and short-lived

A chat response saying 'approved' is not authorization. The execution service must verify a decision from an authenticated, authorized reviewer. Display the exact target, arguments, data exposure and expected consequence before the reviewer decides. Avoid approving an entire open-ended plan.

• Require explicit approval for destructive writes, payments, external messages, sensitive exports and privilege changes.
• Bind approval to an immutable action payload, target resource, requester and expiry; changed arguments require new approval.
• Enforce single-use approvals and recheck current permissions immediately before execution; reject expired or replayed approvals.
• Fail closed when the approval service is unavailable, and use separation of duties for high-impact actions.

3. Treat retrieved content and tool output as untrusted

Webpages, email, documents and tool responses can carry prompt injection. Instructions inside them must never expand permissions or authorize another tool. Prompt-level warnings help, but they are not a security boundary.

• Validate tool arguments against schemas and explicit resource policies outside the model; reject arbitrary commands and URLs.
• Restrict outbound destinations and apply network-level egress controls, including protection against internal-address access.
• Keep secrets out of prompts, retrieved context and tool output; retrieve credentials only within the execution service.
• Preserve tenant and user access boundaries in retrieval, caches, memory and multi-agent handoffs.

4. Observe behavior, not just successful logins

An agent can remain within its nominal scope while producing dangerous volumes or sequences of actions. Monitor exports, repeated failed writes, permission changes and unexpected resource access. Limit what can happen before an alert reaches a person.

• Log identity, initiating user, tool, redacted arguments, policy decision, approval reference, result and correlation ID.
• Protect audit integrity and define retention and restricted access; never log raw credentials or unnecessary personal data.
• Set workflow-specific budgets for actions, data volume, runtime and spend; stop execution when a limit is reached.
• Alert on unusual action sequences and repeated failures, with a named responder and escalation path.

5. Design containment and recovery before launch

Stopping the model is not enough if jobs are already queued. Containment needs to revoke credentials and stop pending execution as well. Treat retries as a security and reliability concern: a repeated payment or destructive write can be worse than a failed task.

• Test an emergency stop that revokes agent access and cancels queued or scheduled actions.
• Use idempotency controls for side-effecting operations; require review after ambiguous outcomes instead of blindly retrying.
• Provide rollback or compensating actions where possible, and document irreversible operations explicitly.
• Prepare an incident runbook covering evidence preservation, containment, affected-user notification and safe restart.

6. Prove the controls under adversarial conditions

A successful demonstration is not a release gate. Test the exact tools and approval paths used in production. Repeat tests when models, prompts, connectors or policies change; a change in one layer can invalidate assumptions elsewhere.

• Test injected instructions in documents and tool output, cross-tenant requests and attempts to invoke denied tools.
• Test approval bypass, altered payloads, expired approvals, replay, revoked permissions and service outages.
• Record concrete evidence of denied actions, audit events and emergency-stop behavior; assign owners to failures.
• Start in read-only or approval-required mode, and expand autonomy only after a documented risk review.

Release decision: evidence before autonomy

Use the checked items as a review aid, not a certification or a security score. If you cannot demonstrate enforcement, approval binding, auditability and containment on the real execution path, keep the agent read-only or approval-required. Security, platform and business owners should agree on the residual risk before production release.

For a practical review, bring an agent's tool inventory, permission policy, approval payload and one redacted execution trace. Those artifacts make the conversation about enforceable controls rather than the model's intentions.