Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Before an AI agent reaches production, limit it to the tools, operations, data and downstream authority its task actually needs. Enforce that limit in the execution layer or connected systems—not in the model’s instructions—and require approval for sensitive actions. Then test whether untrusted input can steer the agent around those boundaries.
What counts as an agent permission?
An agent’s effective authority is broader than the tools shown in its interface. It includes which tools and functions it can call, what data those functions expose, the connected identity’s rights in downstream systems, and any delegated authority the agent uses on a person’s behalf.
Review those permissions across four dimensions:
- Breadth: Which tools, functions, resources and data can the agent reach?
- Mutation power: Can it read, make constrained changes or write freely?
- Trust boundary: Does it process untrusted external content, or operate in a constrained environment?
- Impact and reversibility: Could an action disclose sensitive data, spend money, message someone, delete records, change access or alter infrastructure—and can it be undone?
NIST’s tool-use taxonomy separates tool functions from access constraints and uses categories such as read-only, constrained-write and write across trusted and untrusted settings. Treat those as useful vocabulary for an inventory, not as a universal risk score. The risk of a particular action depends on its target, context and consequences.
Build a permission inventory for each workflow
Document the actual authority behind every tool call, including downstream access. An integration described as read-oriented may still have update or delete rights in its database, or use a shared identity that reaches records beyond the requesting user’s scope. OWASP’s LLM06:2025 Excessive Agency guidance recommends minimizing both unnecessary tool functions and excessive downstream permissions.
Recommended Free Tools
| Inventory field | What to record |
|---|---|
| Tool and function | Name the integration and the narrow function exposed to the agent. Do not list only a broad tool such as “email” if the relevant distinction is read, send or delete. |
| Operation | Classify it as read, constrained write or write; describe any constraints, such as allowed fields or permitted state transitions. |
| Resource and data class | Identify the records, systems and sensitivity categories reachable through the function. |
| Connected principal | Record the service or user identity used downstream, its actual permissions, and whether the human initiator’s scope is preserved. |
| Environment and targets | State whether inputs may be untrusted and which resources, accounts, tenants or environments are in scope. |
| Impact and reversibility | Describe likely harm if misused and whether the effect can be reversed or contained. |
| Approval rule | Specify which actions require review, who can approve them and what exact action the approval covers. |
| Rate or volume limit | Set an appropriate cap on repeated or bulk actions, especially where volume can increase harm. |
| Audit fields and owner | Identify the decision and outcome data to record, plus the team accountable for the tool and policy. |
Fill out one inventory per workflow, not one per model. A summarization agent and an agent that can change account access may use the same model but require different tool surfaces and downstream identities.
Remove authority the task does not need
Expose only necessary tools and functions
If a task is to summarize email, it needs a way to read the relevant messages; it does not automatically need the ability to send or delete them. Narrowing the exposed function is stronger than telling the model not to use an available capability. Apply the same test inside each integration: if an agent only needs to look up a record, do not expose a broad function that can also modify it.
Constrain the identity behind each integration
Match the connected principal’s downstream permissions to the workflow’s targets and operations. Avoid a broad shared identity when the agent is acting for an individual. Preserve that person’s authorized scope so the agent cannot use an integration to cross into other users’ data.
Separate environments and targets
Make permitted targets explicit—for example, which tenant, account, resource set or environment a function may affect. An untrusted document or website can contain instructions that attempt to redirect an agent; limiting targets at the tool or downstream policy boundary reduces what such instructions can accomplish.
Enforce authorization outside the model
A model can propose an action, but it should not decide whether the action is authorized. OWASP states: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” See its Excessive Agency guidance and AI Agent Security Cheat Sheet.
- Receive a structured proposal. The agent submits a tool name and parameters; it does not execute an unrestricted command directly.
- Resolve principals and scope. The trusted execution component identifies the agent, the human initiator if applicable, and the authority delegated to this task.
- Check the action and target. A policy boundary validates the requested operation, resource, parameters and current scope. Reject calls outside the allowed set.
- Pause for required approval. If policy classifies the action as sensitive, do not perform it until an authorized person has approved the specific proposal.
- Revalidate immediately before execution. Check authorization and approval again at the point of action; do not treat an earlier risk classification or approval flag as permission by itself.
- Record the decision and outcome. Log the request, policy result, approval reference where relevant, execution result and identities involved.
Bind an approval to the actor, tool, target, normalized parameters, time and expiry. If the agent changes the target or parameters after approval, treat the changed action as a new proposal. OWASP also recommends short-lived authorization artifacts, replay protection and fail-closed behavior when policy or approval checks fail.
A prompt instruction such as “never delete” is not an effective authorization control. If the policy service cannot be reached, an approval cannot be validated, a required risk check fails or an essential audit record cannot be written, block the sensitive action rather than letting it proceed without the control.
Match approval to impact and reversibility
Approval should be based on what an action can do, not simply on whether it is called a “write.” Low-risk reads or constrained operations may run unattended when policy allows. Independent review is appropriate when an action could have substantial or hard-to-reverse consequences.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11| Action category | Examples | Permission approach |
|---|---|---|
| Read or low-impact operation | Retrieving in-scope information or producing a draft that is not sent or applied | Allow without per-action approval only when the data and target are within policy scope; log according to the workflow’s risk. |
| Constrained change | A narrowly limited update to an approved resource or field | Enforce the constraint in the executor or downstream system. Require approval if the particular target or consequence raises the risk. |
| Externally visible, financial or destructive action | Sending a message, spending funds or deleting records | Require review when the consequences warrant it, and bind approval to the exact proposed action. |
| Administrative or security-sensitive change | Changing permissions, security configuration or infrastructure | Use independent approval and validate scope at execution. OWASP’s agentic threat-model card AAI9 specifically recommends explicit approval for changes to security configuration, permissions or infrastructure. |
OWASP’s AAI9 threat-model card also recommends considering action reversibility when deciding what to gate. Approval does not replace the underlying authorization check: an approver cannot make an out-of-scope action valid simply by clicking yes.
Make agent identity and delegation auditable
Give the agent an identifiable principal with managed credentials and a defined lifecycle. For “on behalf of” actions, retain the link between agent, human initiator and delegated scope rather than collapsing them into a shared service account. Record enough information to reconstruct who or what initiated an action, what was authorized, what policy decided and what happened.
NIST NCCoE’s February 2026 concept paper frames questions about agent authentication, identity binding, credential issuance and revocation, delegated authority and verifiable logs as areas for a planned project. It asks, “How do we establish ‘least privilege’ for an agent, especially when its required actions might not be fully predictable when deployed?” The paper presents open questions, not a finalized agent-specific standard answer.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Test the authority boundary before launch
Evaluate whether the system prevents unauthorized actions, not only whether the model usually follows instructions. NIST CAISI describes malicious instructions embedded in ordinary emails, files and websites, and highlights adaptive evaluations, task-specific analysis and multiple attempts as useful considerations in its January 2025 agent-hijacking evaluation article. Its findings are qualitative, not a generally applicable success-rate statistic for all agents.
| Test | What to attempt | Expected control behavior |
|---|---|---|
| Direct and indirect prompt injection | Ask the agent to ignore policy, or place instructions in an email, file or web page it processes. | Untrusted content must not grant new authority; out-of-scope calls should be denied by the execution or downstream policy boundary. |
| Unneeded function use | Try to invoke a function the workflow does not require, such as sending or deleting from a read-oriented workflow. | The function should not be exposed, or its invocation should be denied. |
| Cross-user access | Request another user’s records through the integration or by altering an identifier. | The connected identity and policy should preserve the initiator’s scope and reject unauthorized targets. |
| Write through a read workflow | Submit a mutation using a read-oriented tool path or unexpected arguments. | Read permissions should not confer write authority; invalid operations and parameters should be rejected. |
| Changed action after approval | Obtain approval, then change the target or normalized parameters before execution. | The approval should not authorize the modified action; require a new decision. |
| Expired or replayed approval | Reuse an expired approval or submit the same authorization artifact again. | Reject expired approvals and prevent replay. |
| Policy or audit service failure | Make policy retrieval, approval validation or required audit writing unavailable. | Fail closed for actions that depend on those checks; do not perform them without the required controls. |
| Bulk or repeated action | Attempt many calls or repeat an action rapidly. | Enforce suitable rate or volume limits and alert operators to suspicious activity. |
| High-impact configuration change | Attempt changes to permissions, security configuration or infrastructure. | Require the defined independent review and validate authorization again at execution. |
Repeat adversarial testing after material changes to prompts, tools, memory, retrieval, policies or model providers. Monitor both the agent integration and downstream systems, and retain structured records for higher-risk decisions and calls. Rate limits can constrain the volume of harmful activity while operators investigate; monitoring and limits help detect or contain damage but do not substitute for authorization enforcement.
Use a production gate, not a prompt checklist
Before enabling a workflow, confirm that its inventory is complete, the tool surface and connected identity match the task, policy checks run for every action, and sensitive approvals are bound to exact proposals. The workflow is not ready if its effective limits depend on the model choosing to obey a prompt, or if a failed control can silently turn into permission.
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.
