Free tools Windows power users keep installed
One-click scans. No signup required.
An AI agent in production should have only the permissions its assigned task requires, limited to specific operations and resources. Enforce that boundary in trusted application code or a policy service—not in the prompt or the model’s own judgment. Let routine, narrowly scoped reads proceed automatically; put writes and other consequential actions behind stronger checks, with human approval for high-impact or irreversible actions.
Start with the action, not the agent
“Give the agent access” is too broad a permission decision. Decide what it may do, to which resource, for which user or workflow, and under what conditions. An agent that only summarizes a customer record may need a scoped read tool, not an integration that can also edit or delete records. Broad or wildcard access increases the potential impact of mistakes and manipulated inputs.
A useful design separates permission into four questions:
- Who: Which initiating user, tenant, or workflow is the action for?
- What operation: Is the agent reading, drafting, writing, deleting, administering, or executing code?
- Which target: Which particular record, account, endpoint, or environment is in scope?
- What additional control: Does this action need a preview, independent validation, or human approval?
Prefer read-only access when reading is sufficient. Where possible, split broad integrations into separate read, write, delete, and administrative tools so a read task cannot invoke stronger capabilities by accident. OWASP’s AI Agent Security Cheat Sheet recommends keeping permissions narrow and validating high-impact actions independently.
#1 Best Overall
Put authorization in trusted execution code
A prompt can tell an agent not to send an email or change a record, but that instruction is not an authorization boundary. The model may propose an action; trusted application code or a policy service must decide whether the exact operation is permitted.
Before a tool call takes effect, the execution component should check the identity, operation, target, parameters, current scope, and any required approval. It should also verify approval for that specific action rather than accepting a general “go ahead” that could be reused for another target or operation. If authorization or approval cannot be verified, block the sensitive action.
OWASP’s guidance puts the distinction plainly: “The agent can propose an action, but a policy service or execution component should independently validate scope, privilege, and approval state before execution.” A model-generated confidence score or risk assessment can inform review, but should not grant the model permission to act.
Set approval gates according to impact
Not every tool call needs a person in the loop. A bounded read from an explicitly authorized source may be automated. An action that changes persistent state, reaches another person, moves money, alters privileges, or affects production needs stronger controls. Base the threshold on reversibility, blast radius, data sensitivity, and potential effects on people or business operations; no single threshold fits every organization.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →| Action | Production default | Control to enforce |
|---|---|---|
| Read a document or record | Allow only when needed for the task | Bind access to the initiating user or workflow and the specific resources; do not expose unrelated data. [OWASP] |
| Search internal sources | Allow within source, tenant, and data-class limits | Treat retrieved and external content as untrusted input. Access to content does not make its instructions authoritative over tools. [OWASP] |
| Draft a message, change, or command | Allow as a proposal, not as an applied action | Keep drafting separate from execution; validate the output and show a preview where useful. [OWASP] |
| Write or modify persistent data | Restrict the operation and target; add approval according to impact | Check authorization in the backend when the action runs. Do not give a read integration write or delete rights it does not need. [OWASP] [OpenAI] |
| Send external messages, issue refunds or payments, delete data, change privileges, or deploy | Require action-specific controls; require human approval for high-impact actions | Independently validate the exact target and normalized parameters, bind approval to that action, and fail closed if review cannot be verified. [OWASP] [OpenAI] [Anthropic] |
| Execute code or access the network | Confine execution and allow only necessary outbound destinations | Use an isolated environment with approved mounts and network access; keep application secrets outside it. [OpenAI] [Anthropic] |
The table is a design starting point, not a universal policy template. An action’s context matters: even a read may be sensitive if it exposes data unrelated to the user’s task, and a routine-looking write may have serious consequences.
Separate the trusted harness from agent-directed execution
When an agent runs code or uses a network, isolate that work from systems that hold authority. Limit filesystem access to approved mounts and outbound connections to approved destinations. Keep long-lived application credentials out of model-visible context and outside the execution environment; where a task needs authenticated access, a trusted broker or proxy can supply it without handing the agent a broad secret.
The trusted harness should retain routing, authentication, policy checks, approvals, audit records, and recovery controls. The sandbox should run only the model-directed workload with the minimum access it needs. OpenAI describes sandboxing and controlled network access for agent coding environments in its Codex documentation; Anthropic documents permission controls for managed agents. Product capabilities and labels can change, so verify current platform documentation before relying on a particular setting.
Implement the permissions in six steps
- Inventory tasks and tools. List every data source and operation the agent needs. Remove unused tools, and separate read, write, delete, and administrative capabilities where possible.
- Bind identity and scope. Use an identity tied to the initiating user, tenant, or workflow. Constrain it to the task and target resource, and prefer short-lived, narrowly scoped access where supported. Do not pass broad service credentials into model-visible context.
- Check policy at execution time. Before each call takes effect, validate the identity, operation, target, parameters, current scope, and approval state in trusted code or a policy service.
- Set risk-based approval thresholds. Require a person to confirm high-impact or irreversible actions. Show the exact action and target; if authorization or approval is unclear, stop the action.
- Isolate untrusted execution. Confine code execution and restrict network and filesystem access. Keep credential management, approvals, audit, and recovery in trusted infrastructure.
- Log and test the controls. Record enough decision and action metadata to investigate consequential operations, without logging secrets or unnecessary personal data. Test adversarial inputs and the authorization path before launch and after material changes to prompts, tools, memory, retrieval, policies, or model providers. OWASP recommends structured security testing around such changes.
What to verify in a platform’s permission settings
Platform permission modes are implementation options, not substitutes for deciding what your application should authorize. When evaluating them, check whether a mode automatically allows actions, asks for approval, or evaluates a policy on a trusted server. Then verify whether controls apply per tool and operation, bind identity and target parameters, and support action-specific approval and logging. Check sandbox, filesystem, network, and credential boundaries separately: a tool approval setting alone does not establish those protections.
For example, Anthropic’s managed-agent documentation describes automatic, approval, and server-evaluation policies. Confirm the current behavior and scope in the current permissions documentation before adopting a product-specific configuration.
Make failed checks fail closed
Authorization and approval are runtime controls, not setup tasks to perform once and forget. A policy check should be able to stop an action when identity, scope, target, parameters, or approval is missing or uncertain. Audit records should let operators reconstruct consequential decisions without exposing credentials or collecting unnecessary personal data. Retest after material changes to the agent’s tools, prompts, memory, retrieval sources, policies, or model provider.
The practical test is simple: if an agent is manipulated into proposing an action outside its assigned task, can trusted execution code still prevent it? If the answer depends on the agent obeying its prompt, the permission boundary is in the wrong place.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
