Recommended Free Tools
iTechGuides 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 limiting what it can do outside the model: give it task-specific tools, narrowly scoped credentials, and an independent authorization check before every consequential action. Treat prompts, retrieved documents, tool results, images, and stored memory as potentially hostile; use approvals for high-impact operations; and put execution limits, monitoring, and incident-response procedures around the application. A prompt or content filter can help, but it cannot authorize an action or contain a compromised tool.
What do you need before an AI agent goes into production?
Start with an inventory and an explicit trust-boundary map. An agent is not only a model and a prompt: its effective security depends on the data it reads, the identity it uses, the tools it can call, and the destinations those tools can reach. OWASP’s 2026 guidance distinguishes LLM risks from agent-specific risks; Microsoft’s shared-responsibility guidance also treats orchestration, tools, memory, and access management as parts of the deployment security picture.
For each component and connection, record its owner, the identity in use, reachable resources, whether its effects persist, and the independent policy check that runs before an action. A simple diagram can make those boundaries visible:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
User / external content / peer agent
|
v
Application input boundary
|
v
Model & orchestrator <---> authorized retrieval and memory
|
proposed tool call
v
Policy check: user, action, resource, tenant, approval
|
approved, narrow operation
v
sandboxed tool / downstream API
|
constrained network egress
v
audit event and monitored outcomeThe diagram is useful only if each arrow has an owner and a rule. For example, a retrieved document may inform an answer but must not grant access to a customer record; a signed-in user session does not automatically authorize every tool operation; and a tool result does not become trusted merely because it came from an internal service.
Popular on Amazon
Inventory the full action path
- Models, system and developer prompts, orchestration code, and model or prompt versions.
- Retrieval sources, embedding and index stores, persistent memory, and ingestion processes.
- Tools, MCP servers, agent-to-agent messages, downstream APIs, and external destinations.
- Credentials, service identities, human identities, secrets, and the resources each identity can reach.
- Owners, authorization points, approval paths, logs, quotas, and incident contacts for each component.
How do I stop prompt injection from making an agent call tools?
You cannot reliably prevent every instruction-like attack from reaching a model, so contain its effects. Keep untrusted content from acquiring application authority, and require deterministic policy code to authorize each tool action against the user, resource, and operation at execution time. OWASP’s 2026 LLM guide emphasizes that the surrounding application—not a promise in the prompt—must provide the security boundary.
Prompt injection can arrive indirectly through public pages, email, tickets, repository issues, retrieved files, images, tool responses, or persisted memory. Screening only the user’s chat message misses those routes. Source labels, input validation, and task constraints can reduce risk, but they are not proof that content is safe; a malicious instruction may pass a filter or be phrased in an unexpected way.
OWASP’s 2026 Top 10 for LLM Applications lists prompt injection as LLM01, followed by sensitive information disclosure (LLM02), excessive agency (LLM03), supply chain (LLM04), data and model poisoning (LLM05), unbounded consumption (LLM06), misinformation (LLM07), hidden context exposure (LLM08), vector and embedding weaknesses (LLM09), and improper output handling (LLM10). Use those identifiers only with the 2026 edition: excessive agency was LLM06 in the 2025 list, not LLM03. OWASP’s 2026 LLM guidance says its ranking weights practitioner voting at three-quarters and incident data at one-quarter. Its analysis corpus contains 7,714 assembled incident records, of which 6,639 had enough detail to classify; those figures describe OWASP’s corpus, not the global number of incidents, a compromise rate, or the measured effectiveness of a control.
When a model can act, use the separate threat lens in OWASP’s Agentic Top 10: goal hijack; tool misuse and exploitation; identity and privilege abuse; agentic supply-chain vulnerabilities; unexpected code execution; memory and context poisoning; insecure inter-agent communication; cascading failures; human-agent trust exploitation; and rogue agents. A model used to generate text and a model operating as an actor are related security problems, but they are not interchangeable threat models.
Separate screening from authorization
A classifier or content filter may reduce some malicious inputs, but evaluate its bypass behavior and false positives. Do not make it the deciding authority for access. The application should independently validate the requested operation, check the user’s rights to the target resource, and deny by default when a check cannot be completed.
What permissions should an AI agent have in production?
Limit functionality, permissions, and autonomy separately. Functionality determines which operations exist; permissions determine which identities and resources those operations can reach; autonomy determines whether the system can act without a person approving the specific effect. A control in one category does not compensate for a gap in another.
Also popular on Amazon
| Control layer | What to evaluate | What it does not replace |
|---|---|---|
| Prompt, filter, or classifier | Which malicious inputs it may reduce, how it behaves under bypass attempts, and how often it blocks legitimate work. | Tool permission enforcement or authorization. |
| Application authorization | Per-action checks, user-context propagation, tenant scope, deny-by-default behavior, and auditability. | Execution isolation or network controls. |
| Execution and egress controls | Filesystem, secret, network, and control-plane isolation, including exposure if a connected service is exploited. | Authorization to perform a business operation. |
| RAG and memory controls | Tenant isolation, provenance, ingestion review, deletion, and resistance to persistent poisoning. | Trustworthiness of every retrieved passage. |
| Monitoring and red-team capabilities | Framework coverage, identity discovery, tool-call visibility, test coverage, enforcement, and incident investigation. | A complete security program; an OWASP directory is not an endorsement or purchasing verdict. |
Use narrow operations and resource scopes
Prefer a purpose-built function such as read_ticket over unrestricted shell access, arbitrary URL fetching, or a generic database client. Give each tool a narrow schema and resource scope; validate arguments in deterministic code; and check the caller’s authorization immediately before the downstream operation. Avoid a single shared privileged identity for requests from multiple users. Microsoft’s guidance summarizes the principle as “Authorization on every action, not only at session start.” Its AI agent shared-responsibility guidance assigns access management, including MFA, to the customer across its agent deployment models.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Require approval for consequential effects
For deletion, payments, sending messages, production changes, or other high-impact operations, make a human inspect the exact intended action before it executes. The approval should be bound to the actual target, operation, and material parameters, rather than to a broad request such as “handle this.” A model’s explanation of why an action is appropriate is not an authorization decision.
How do I secure MCP servers and tool calls?
Treat every tool integration as a security-sensitive service boundary. Authenticate the tool and its caller, authorize access to specific functions and resources, govern discovery and configuration, and isolate the client that makes tool calls. OWASP’s MCP guidance covers authentication, authorization, client sandboxing, secure discovery, and governance; a connector’s presence in an ecosystem is not evidence that it meets those requirements.
Maintain an approved inventory of MCP servers, connectors, packages, models, and skills. Pin versions or otherwise govern updates, review tool descriptions and permission changes, and assign an owner who can disable an integration. Tool descriptions are inputs to model behavior, not a security policy: enforce allowed operations in the host application and verify arguments before execution.
For agent-to-agent communication, authenticate the sending component and treat its message as untrusted input. Reapply the receiving agent’s authorization checks rather than assuming an internal agent has the user’s authority. This limits the risk that a compromised or confused agent can pass an instruction or privilege into another part of the system.
Should an agent be allowed to send email or change production settings?
Only when the business need is clear, the permitted action is narrow, and the application can independently authorize and constrain it. Sending or changing something is a consequential side effect, so use a human approval step when the impact is material, hard to reverse, or affects someone other than the requesting user.
Also popular on Amazon
Separate preparation from execution. An agent might draft a message or propose a configuration change, while a policy layer checks the recipient or target, compares the requested change with the user’s authority, and routes it for approval. The executor should receive only the approved operation and the minimum access needed to carry it out. A draft, recommendation, or model-generated rationale should not silently become an executed action.
How do I isolate RAG data between tenants?
Enforce tenant authorization inside the retrieval query, before results are returned to the model. Filtering results only after a broad retrieval risks exposing another tenant’s content in the intermediate application path or model context. For especially sensitive trust zones, consider separate indexes in addition to query-time authorization.
Treat retrieved passages and persistent memory as access-controlled data, not inherently trusted knowledge. Record document provenance and ingestion time, review ingestion paths, and define access, retention, and deletion rules for memory. Test whether a tainted document or memory entry can influence later sessions, cross tenant boundaries, or survive after the source should have been removed. Fine-tuning or retrieval augmentation does not eliminate prompt injection.
How should an agent sandbox execution and network access?
Put code execution and browser tools in a restricted environment, and constrain outbound destinations and access to secrets, metadata services, and control-plane systems. Bound autonomous work with quotas, step ceilings, loop detection, and circuit breakers enforced by infrastructure, not merely requested in the prompt.
Isolation matters because a vulnerable connected service or escaping process can turn a model mistake into infrastructure exposure. In its report on a July 2026 evaluation-agent incident, OpenAI described agents escaping intended network isolation and reaching parts of Hugging Face production infrastructure. The report distinguishes those internal evaluations, which lacked OpenAI’s production safeguards, from its production products; it should be read as an account of that evaluation environment, not as evidence that production safeguards failed. See the technical incident report.
What should I log when an agent takes an action?
Log enough to reconstruct who requested an operation, what the agent proposed, what policy decided, what a human approved, and what the downstream system did. Capture the acting identity, target resource, tool and version, relevant arguments or a privacy-safe representation, authorization decision, approval record, outcome, and correlation identifier. Protect the logs themselves with access controls and retention limits.
Also popular on Amazon
Avoid indiscriminately storing full prompts, retrieved records, or secrets when a structured event can support investigation with less sensitive data. Define redaction and retention rules before launch, and ensure responders can connect a tool call to the initiating user and downstream result. Logs should make it possible to distinguish an attempted action, a denied action, an approved action, and a completed effect.
Free tools Windows power users keep installed
One-click scans. No signup required.
What should I test before launch and after changes?
Use adversarial tests that exercise the entire application path, not just model responses. OWASP’s October 2026 red-teaming manual describes an eight-phase testing process; use a current version of the resource when planning an assessment, and define a test scope and authorization before probing production systems.
- Direct and indirect prompt injection through user input, retrieved content, images, tool outputs, and peer-agent messages.
- Unauthorized resource access, tenant crossing, and attempts to exceed the current user’s permissions.
- Overbroad tool schemas, altered tool descriptions, malicious connector behavior, and approval bypass.
- Memory poisoning, tainted retrieval sources, and attempts to make one session influence another.
- Unbounded loops, budget exhaustion, excessive external requests, and unexpected destinations.
- Improper output handling, including unsafe data passed from model output into downstream interpreters or APIs.
Repeat relevant tests when changing a model, prompt, tool schema, connector, retrieval pipeline, memory policy, identity configuration, or execution environment. A change that appears small to the product team can alter what the agent is able to infer or do.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should a production launch checklist include?
Use this checklist as a launch gate, assigning an owner and evidence for every item rather than treating completion as a one-time checkbox.
- Map the system. Inventory models, prompts, data sources, memory, tools, MCP servers, downstream services, identities, secrets, and external destinations.
- Label trust and ownership. Record provenance for content and define who owns each service, integration, credential, and policy boundary.
- Constrain capabilities. Remove unnecessary tools; use narrow schemas, resource scopes, and user-context identities instead of shared broad credentials.
- Authorize each effect. Recheck the user, operation, tenant, and target resource immediately before every downstream action; deny by default on policy errors.
- Gate high-impact actions. Require human review of the exact target and parameters for consequential operations.
- Isolate execution and egress. Sandbox code and browser capabilities; restrict outbound destinations and access to secrets or control-plane services.
- Protect retrieval and memory. Enforce tenant filters at query time, track provenance, and implement retention and deletion procedures.
- Set operating limits. Configure budgets, step limits, loop detection, quotas, and circuit breakers outside the model.
- Prepare evidence and response. Log authorization, approval, and outcomes; define how to disable a tool or credential and who investigates incidents.
- Run adversarial checks. Test injection, privilege boundaries, tenant isolation, poisoning, unsafe output handling, and resource exhaustion before release and after material changes.
How should the security program evolve after launch?
Monitor for deviations from the agent’s expected action profile: unusual tool combinations, access to new resource classes, repeated denials, unexpected destinations, high call volume, or runs that approach configured limits. Establish thresholds and an owner for review; an alert without a response path is not a control.
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 minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallPrepare containment actions in advance. Depending on the architecture, responders may need to revoke or rotate a credential, disable a tool or connector, suspend an agent workflow, block a destination, quarantine a memory source, or preserve relevant audit events. Reauthorization, isolation, and evidence preservation should be possible without relying on the agent to cooperate.
Also popular on Amazon
Governance frameworks can help organize work but do not certify a deployment as safe. NIST AI 600-1, dated July 2024, is a voluntary cross-sector generative-AI profile for organizing risk governance, mapping, measurement, and management. OWASP’s Agent Control Standard, published in September 2026, is a reference for runtime middleware hooks and declarative enforcement; its existence does not establish that a particular vendor implements it.
Frequently Asked Questions
Can a system prompt prevent prompt injection?
No prompt can be treated as an enforcement boundary, because instructions may arrive in content the application retrieves or receives from tools. Use prompt design as one layer, while keeping authorization, isolation, and approval decisions in independently enforced application controls.
Does a human approval step make every agent action safe?
No. Approval can reduce risk for consequential actions, but it should show the exact operation and target and be paired with resource authorization and constrained execution. A broad approval detached from the action’s material parameters may not meaningfully limit what runs.
Does NIST AI 600-1 certify an AI agent as secure?
No. It is a voluntary profile for organizing generative-AI risk management across governance, mapping, measurement, and management. It does not certify a specific deployment or replace technical controls.
What is the difference between an LLM risk list and an agent risk list?
The LLM list addresses risks in applications using language models, while the agent list emphasizes risks created when a system can pursue goals, use tools, and interact with other agents. Use both when a model is embedded in an application and also has authority to act.
