Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Secure an AI agent by treating it as an actor that can take consequential actions—not merely as a text generator. Give each agent a distinct identity, restrict its tools and credentials, and put a deterministic authorization check before every tool call. Treat user input, retrieved content, memory, and messages from other agents as untrusted; require approval bound to the exact action for sensitive operations; and limit execution, retries, and spend. Log decisions safely and repeat adversarial tests before launch and after significant changes.
Why do AI agents need action-level security?
An agent can interpret a request, plan multiple steps, select tools, access data, preserve state, and act through connected services. A harmful outcome can therefore come from a sequence of tool calls, even if the agent’s final text looks harmless. A malicious instruction embedded in a webpage, email, or document can influence what the agent does next.
NIST’s Center for AI Standards and Innovation describes this as agent hijacking: indirect prompt injection in which malicious instructions enter data the agent ingests, exploiting a failure to separate trusted instructions from untrusted content. In a January 17, 2025 post about its AgentDojo evaluation, NIST reported attack-success rates from 11% for the strongest baseline attack to 81% for the strongest newly developed attack on a held-out set of user tasks. Those figures describe that model- and evaluation-specific setup; they are not a general failure rate for AI agents. NIST CAISI’s AgentDojo findings
Recommended Free Tools
The practical security boundary is the action itself. A model’s judgment that a request is safe—or that a piece of content is trustworthy—must not substitute for authorization enforced by the system that executes the tool call.
#1 Best Overall
What risks should a threat model include?
OWASP’s agentic-applications taxonomy is useful for identifying areas to assess, not for predicting which threat is most likely in a particular deployment. It includes goal hijacking, tool misuse, identity and privilege abuse, supply-chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. OWASP Top 10 for Agentic Applications
Translate those categories into the actual paths an agent can take: what data it can read, what operations its tools can perform, what it can store, which other agents it can contact, and what can happen if a step is repeated or runs indefinitely. Include sensitive information in logs or memory, manipulated approvals, malicious configuration, and runaway spending in that review; OWASP’s security guidance also calls out these practical concerns. OWASP AI Agent Security Cheat Sheet
How should you control an agent’s actions?
1. Give each agent a distinct, accountable identity
Identify the agent separately from the person who initiated a task and from the tools it uses. Keep an owner and lifecycle for each agent, and preserve the initiating user’s authorization where appropriate. Avoid a broad, standing identity that allows the agent to act beyond that user’s rights. Microsoft’s overview of security for AI agent identity
Free tools Windows power users keep installed
One-click scans. No signup required.
2. Grant only the access each task needs
Limit the available tools to those needed for the workflow, and scope each tool’s access to specific resources and operations. Separate read from write access; use short-lived credentials where practical; and evaluate access to the particular target resource, not just the tool in general. Listing a tool as available to the model must not itself authorize its use.
Check authorization again for each action. A permission granted when a session starts may not be sufficient for a later call involving a different operation, customer, or resource. OWASP recommends least privilege, while Microsoft’s agent-security guidance emphasizes evaluating inputs, tool calls, and accessed data at call time. OWASP’s agent security controls · Microsoft’s guidance on securing agents
3. Enforce authorization outside the model
Place a deterministic policy gate between the agent’s proposed action and the tool that performs it. For each call, evaluate the user or other initiating actor, tenant or customer, agent identity, tool, operation, target resource, applicable scope, and whether approval is required. Deny unknown tools. Fail closed if policy lookup, approval validation, or audit logging fails; do not continue with the action merely because the model requested it.
Rank #3
This boundary should be enforced by the application or execution layer, not by instructions asking the model to obey policy. Prompt filters can help identify suspicious content, but they are not the authoritative permission check.
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 →4. Bind approval to the exact high-impact action
For destructive, financial, administrative, or externally visible operations, require an independent policy or execution layer to validate the proposed action. Bind approval to the actor, tool, target, normalized parameters, time, and expiry. Reject replayed or expired approvals, and require a new approval if the target or parameters change. A generic “user confirmed” flag does not establish that the user approved the action now being executed.
Consider step-up authentication for especially consequential operations such as payments, privilege changes, bulk deletion, account recovery, or production deployment. Approval should authorize the specified operation, not grant the agent a wider permission for the rest of a session.
How do you protect the data and trust boundaries around an agent?
5. Keep untrusted content separate from instructions
Handle user input, retrieved documents, webpages, email, API output, and content passed from another agent as untrusted data. Preserve the distinction between those sources and trusted system instructions, and validate or sanitize content before using it. A model’s classification of a document as safe must not grant permission to execute a tool or override the action gate. NIST identifies the failure to separate trusted instructions from external data as the underlying weakness behind agent hijacking. NIST CAISI’s explanation of agent hijacking
6. Isolate memory and minimize sensitive data
Track the provenance of information before storing it, and treat stored memory and retrieved context as possible sources of malicious instructions. Separate memory between users and sessions, set retention and size limits, and avoid persisting credentials, personal data, or confidential information unless the workflow requires it and appropriate protections are in place. Redact sensitive values from logs as well as from memory.
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 & 117. Constrain code execution and agent-to-agent communication
Sandbox code execution and tightly scope filesystem and network access. If agents communicate or delegate work, authenticate the communicating agents where needed, validate each incoming message at the receiving agent, and apply authorization again rather than inheriting trust from the upstream agent. Check that delegation cannot silently increase privilege, and account for replay and cascading failures. OWASP’s agent security guidance
Best Value
8. Put hard limits on loops, retries, and spend
Set maximums for steps, retries, recursion depth, tool-chain length, tokens, runtime, and spend. Add loop detection and circuit breakers so a repeated or stalled sequence cannot run without bound. Make high-impact actions idempotent where possible, and define how duplicate execution is handled. These limits reduce the impact of both accidental orchestration failures and misuse that drives costs or repeats side effects.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How does deployment model affect responsibility?
Responsibility changes with how much of the agent stack the organization operates. Microsoft’s shared-responsibility guidance distinguishes SaaS agents, managed-platform or PaaS agents, and self-hosted or IaaS agents; its model is illustrative vendor guidance, not an independent comparison or legal conclusion. The more infrastructure and orchestration the customer operates, the more of those controls it must configure and maintain. Microsoft’s shared-responsibility guidance for AI agents
| Deployment model | Responsibility direction | Questions to settle before deployment |
|---|---|---|
| SaaS agent | The provider operates more of the service; the customer still needs to understand and configure the controls available to it. | Who controls agent identity, tool access, memory isolation, action approvals, logs, and incident response? |
| Managed platform or PaaS agent | Responsibility is shared between platform provider and customer. | Which runtime, orchestration, identity, and logging controls does the platform operate, and which must the customer configure? |
| Self-hosted or IaaS agent | The customer takes on more responsibility for orchestration, tools, permissions, memory, identity, and runtime controls. | Who patches and operates the runtime, secures connectors and credentials, enforces authorization, and responds to incidents? |
Do not infer that a deployment label guarantees a particular safeguard. Confirm the actual division of responsibility with the provider and document which team owns each control.
How should you test and monitor agent security?
Test specific failure paths before release
Build repeatable tests around the actions and boundaries in the threat model. Include prompt override through retrieved content, unauthorized tool use, privilege escalation, memory poisoning, data exfiltration, approval bypass, runaway loops, and inter-agent chaining. Record whether the system blocks the action at the execution boundary, not only whether the model produces a safe-sounding response.
Run the test set before production and after material changes to prompts, tools, permissions, models, memory, or orchestration. Refresh the cases as the system and its threat environment change. OWASP’s security guidance and NIST’s agent-hijacking evaluation provide useful grounding for these test categories. OWASP AI Agent Security Cheat Sheet · NIST CAISI’s agent-hijacking evaluation
Log enough to reconstruct decisions safely
Use structured decision metadata to connect the initiating request, agent, policy check, tool call, resource touched, approval, and outcome. Redact secrets and sensitive information, and control access to the logs. This record helps an organization understand whether a tool call was authorized and where a failed control occurred without turning logs into another store of credentials or private data.
Quick Recap
What is a practical pre-launch checklist?
- Each agent has a named owner, distinct identity, and defined lifecycle.
- Tools and credentials are limited to the operations and resources the workflow needs.
- A deterministic gate checks identity, scope, target, and approval before every tool call.
- Sensitive actions require approval bound to the exact parameters and target, with expiry and replay protection.
- External content, memory, API results, and inter-agent messages are treated as untrusted.
- Memory, code execution, and agent communication are isolated and constrained.
- Limits exist for steps, retries, runtime, tokens, and spend; duplicate high-impact actions are handled explicitly.
- Structured logs preserve decision traceability while redacting sensitive values.
- Adversarial tests cover the real tools and data paths, and are rerun after material changes.
- Provider and customer responsibilities are documented for the chosen deployment model.
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.
