Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides 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
Short answer: Secure an AI application as a privileged, connected system—not as a chatbot that can be trusted to police itself. Put authorization, identity, data boundaries, tool permissions, output validation and monitoring outside the model; treat prompts and retrieved content as untrusted input; and assess the model, training data, platform and integrations as one supply chain. The controls below map the main risks identified by the 2025 OWASP Top 10 for LLM and Gen AI and NIST guidance on generative-AI risk, agent identity and agent-hijacking evaluations.
What security controls should we use for AI agents?
Start with five control layers: a unique identity for every agent, least-privilege authorization at the system boundary, strict separation of instructions from task data, protection of sensitive information, and continuous validation and monitoring. Add supply-chain review and abuse testing before an agent can act on production systems.
These controls matter because a language model does not inherently know which text is a trusted instruction and which text is merely data. NIST’s Design Tenets for Agent Identity Management Systems states: “By design, Large Language Models (LLMs) accept data and instruction as a single stream of tokens through a single interface.” The policy boundary therefore has to be implemented by the surrounding architecture, not inferred from the model’s response.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →| Control area | What to implement | Failure it limits |
|---|---|---|
| Identity and access | Give each agent a distinct identity, short-lived credentials, narrowly scoped permissions and a human-approval path for high-impact actions. | Excessive agency, confused-deputy attacks and lateral movement |
| Data boundaries | Filter retrieval sources, classify data, enforce authorization outside the model and keep unnecessary secrets out of context. | Sensitive information disclosure and indirect prompt injection |
| Instruction handling | Treat user prompts, documents, web pages, emails and tool results as untrusted; isolate policy from content and constrain tool calls. | Prompt injection and agent hijacking |
| Output safety | Validate schemas, encode or sanitize output, apply business rules and re-check authorization before downstream execution. | Improper output handling and unsafe transactions |
| Supply chain | Track model, data, platform, plugins, embeddings and update provenance; review changes and rollback paths. | Data/model poisoning and third-party compromise |
| Detection and response | Log prompts, retrievals, tool requests, approvals, denials and data egress; alert on anomalous behavior and preserve evidence. | Unnoticed abuse, leakage and recurring incidents |
How do we prevent an AI agent from accessing data it should not see?
Enforce access before retrieval and again before an action, using the user’s and agent’s identities. Do not rely on a system prompt such as “never reveal confidential information”; a prompt is not an access-control mechanism.
Popular on Amazon
- Define the task boundary. List the exact data stores, fields, APIs and operations the agent needs. Everything else should be denied by default.
- Assign a separate agent identity. NIST’s December 2025 initial preliminary draft AI Cybersecurity Framework Profile suggests giving each AI agent a unique identity and credentials and applying precautions used for privileged users. It is draft guidance, not a final requirement.
- Use delegated, short-lived credentials. Mint credentials for one task or session, constrain their scope and audience, and revoke them when the task ends. Keep master keys, signing secrets and unrelated tenant data outside the model context.
- Filter retrieval by authorization. Apply tenant, role, document and field-level policies before content reaches the retrieval index or model. A vector search result is not proof that the requester is entitled to read the source.
- Re-authorize every consequential tool call. Check the current user, agent identity, target resource, parameters and transaction limits in a gateway that does not depend on model judgment.
- Require approval for irreversible actions. Deletion, money movement, external messaging, code deployment and privilege changes should pause for a human or a deterministic policy engine.
NIST explains why this is architectural work: policy must be enforced “around the agent and between the systems, data, credentials, and environments with which the agent will interact.” One practical implication is to expose only the minimum information needed for the next step, rather than handing the model a broad database snapshot.
Also account for the confused-deputy problem. NIST writes that linking and delegating agentic tasks helps mitigate “confused deputy” attacks, “where a prompt injection is used to convince an agent with broadly scoped access to execute an action they otherwise would not.” A user’s request should authorize only the intended operation, not silently grant the agent the user’s full authority.
Can prompt injection cause data leakage or unauthorized actions?
Yes. A direct prompt injection is malicious text supplied directly to the model. An indirect prompt injection hides instructions in content the application retrieves or processes, such as a document, email, web page or issue. NIST’s Generative Artificial Intelligence Profile describes demonstrations in which indirect injections were used to steal proprietary data or run malicious code remotely; that is a documented mechanism, not a claim that every deployment is equally vulnerable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Agent hijacking is a particularly consequential form of indirect injection because the model can call tools. NIST’s January 2025 technical blog says: “Currently, many AI agents are vulnerable to agent hijacking, a type of indirect prompt injection in which an attacker inserts malicious instructions into data that may be ingested by an AI agent, causing it to take unintended, harmful actions.” The risk rises with autonomy, broad permissions and untrusted inputs.
Controls for injection-resistant workflows
- Mark provenance and trust level for every input, and keep retrieved text in a data channel that cannot redefine policy.
- Use allowlisted tools with fixed schemas, parameter bounds, rate limits and destination restrictions.
- Ask the model to produce a proposed action, then have deterministic code validate authorization, data destinations and business rules.
- Strip or quarantine suspicious instructions in retrieved content instead of asking the model to decide whether they are safe.
- Separate planning from execution. A planner may suggest steps, while a constrained executor performs only approved operations.
- Log the source document, relevant excerpts, model output, tool arguments, policy decision and approval so an incident can be reconstructed.
Prompt injection cannot be solved by a stronger system prompt alone because the model still receives instructions and data through the same token stream. Defense in depth should assume an injection may influence the model and limit what influence can achieve.
Also popular on Amazon
What counts as sensitive information disclosure in an AI system?
Disclosure includes personal, financial, health, business, security and legal information exposed through answers, logs, retrieval results, tool calls, training pipelines or error messages. OWASP lists “Sensitive Information Disclosure” and “System Prompt Leakage” in its 2025 taxonomy. The taxonomy names the risk categories but does not provide a universal probability of disclosure.
Treat system prompts as configuration, not a secret store. If a prompt contains an API key, private algorithm, customer record or policy that must remain confidential, assume it can eventually be revealed through output, logs, debugging or a compromised component. Store credentials in a secret manager, retrieve them only in a trusted execution layer and return opaque references or filtered results to the model.
Useful leakage controls include:
- Minimize context: send only the fields and records required for the current operation.
- Redact and tokenize: mask identifiers before inference where the task does not require raw values.
- Partition tenants: use separate indexes, encryption keys or policy domains where cross-tenant exposure would be severe.
- Control telemetry: define retention, access and redaction rules for prompts, completions, traces and provider logs.
- Inspect egress: detect sensitive values in responses, tool arguments, outbound requests and generated files.
- Test denial paths: try requests for another user’s records, hidden instructions, credentials and system-prompt content, then verify that the system denies them without leaking confirming details.
What does AI model supply-chain security include?
It includes more than open-source packages. OWASP’s “Supply Chain” category covers training data, models and platforms, while NIST’s Adversarial Machine Learning taxonomy emphasizes that model development spans multiple stages and organizations. Review the provenance and change controls for every component that can alter behavior or expose data.
| Component | Questions for procurement and engineering |
|---|---|
| Training and fine-tuning data | Who supplied it? What licenses, consent, filtering, poisoning checks and version records exist? Can a changed dataset be detected and rolled back? |
| Base and adapted models | What model and version are deployed? What safety evaluation, update policy, weights access and vulnerability disclosure process are documented? |
| Inference platform | Where are prompts, outputs and telemetry processed? Which subcontractors, regions, retention settings and administrative paths apply? |
| Retrieval and embeddings | How are documents ingested, authorized, deleted and re-indexed? Can poisoned or malicious content persist in the index? |
| Tools, plugins and agents | What permissions, network destinations, update mechanisms and signing or integrity checks do they have? |
| Operations | How are changes approved, monitored, reported and reversed when behavior or ownership changes? |
Data poisoning is a supply-chain or development-stage attack: an adversary compromises training or tuning data to manipulate later outputs or operation. It is different from runtime prompt injection, which attempts to steer an already deployed system through input or retrieved content. Both can produce harmful behavior, so controls and evidence should identify where in the lifecycle the manipulation occurred.
Request a component inventory, model and dataset hashes or version identifiers where available, evaluation summaries, update notifications, incident contacts and deletion or rollback commitments. If a provider cannot answer, record that uncertainty as a risk rather than assuming the component is safe.
Also popular on Amazon
How should we control excessive agency and tool use?
OWASP’s “Excessive Agency” category describes systems that can act through tools, extensions or plugins with more authority than the task requires. Reduce agency by narrowing permissions, limiting autonomy and inserting deterministic checks between the model and every consequential system.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →- Expose purpose-built functions instead of unrestricted shell, database or network access.
- Use read-only tools by default; separate read, draft and commit operations.
- Set transaction ceilings, destination allowlists, timeouts, concurrency limits and quotas.
- Require fresh user confirmation when an action changes its scope, target or cost.
- Make each delegated sub-agent’s identity and permissions visible in logs and approval screens.
- Fail closed when a tool response is malformed, authorization is unavailable or policy evaluation times out.
Unbounded consumption is another OWASP risk: loops, oversized context, repeated tool calls or adversarial inputs can exhaust compute or budgets. Add quotas and circuit breakers, and alert when an agent’s behavior departs from normal task patterns.
What should we validate in AI outputs and retrieval systems?
Never pass generated text directly into a command, query, template, permission change or customer communication without validation. OWASP identifies “Improper Output Handling,” “Vector and Embedding Weaknesses,” and misinformation as distinct risk areas.
Use strict schemas and type checks for structured output; escape content for its destination; parameterize database queries; validate URLs, recipients and file paths; and apply business rules after generation. For retrieval, authenticate the source, scan content, preserve provenance, enforce deletion and access policies, and prevent untrusted documents from changing tool permissions. A model’s confidence or fluent wording is not an authorization signal.
How do we test AI agents for prompt injection and hijacking?
Build evaluations around realistic hostile content, not only clean benchmark prompts. NIST’s agent-hijacking evaluation work used scenarios from AgentDojo and additional scenarios in a particular model and setup at that time. Treat that as a documented evaluation approach, not a universal ranking or a current guarantee of safety.
Also popular on Amazon
- Map attack surfaces. Inventory user prompts, email, documents, web content, tickets, code, tool results and memory that can reach the agent.
- Define unacceptable outcomes. Examples include cross-tenant reads, secret disclosure, unauthorized deletion, external messages, code execution and policy bypass.
- Seed hostile cases. Insert instructions that ask the agent to ignore policy, exfiltrate data, call an unexpected tool or alter retrieved content. Include indirect injections in realistic documents.
- Measure control behavior. Record whether retrieval was blocked, the action was denied, approval was requested, sensitive output was redacted and alerts fired.
- Vary permissions and models. Repeat with read-only versus write access, different tool scopes, context lengths and model versions. Results apply only to the tested configuration.
- Retest after change. Run the suite when prompts, models, indexes, tools, policies or providers change, and retain the versioned evidence.
Evaluation should include human review of borderline cases and a recovery drill: revoke credentials, disable a tool, isolate an index, notify affected parties and restore a known-good configuration. No evaluation set proves that all future injections will fail.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should organizations compare the risk of two AI deployments?
Use a documented, context-specific comparison rather than a single “secure model” score. A deployment with a smaller model may be riskier if it has unrestricted write access, while a more capable model may be manageable when it is read-only and tightly mediated.
| Comparison axis | Lower-risk direction | Questions to document |
|---|---|---|
| Autonomy | Human approval and bounded workflows | Can it act without confirmation? Are actions reversible? |
| Data sensitivity | Minimal, classified and filtered context | What personal, financial, health, legal or proprietary data can it see? |
| Tool authority | Read-only, allowlisted, narrow functions | Can it write, delete, send, execute code or change permissions? |
| Input exposure | Curated, authenticated content | How much untrusted web, email, document or user content is ingested? |
| Supply-chain complexity | Few components, traceable versions and rollback | Who supplies the model, data, platform, embeddings and plugins? |
| Impact | Low-consequence, recoverable actions | What happens if an instruction is followed incorrectly or data leaves the boundary? |
This framework synthesizes OWASP’s risk categories with NIST’s access, attack-stage and lifecycle guidance; it is not a standardized scoring rubric. Record assumptions and evidence so risk owners can challenge the decision.
What is a practical rollout checklist?
Before production, require evidence for each item:
- Named owner, business purpose, data classification and impact assessment.
- Agent identity, credential lifecycle, least-privilege roles and emergency revocation.
- Authorized retrieval sources, tenant isolation, retention and deletion behavior.
- Tool inventory with schemas, allowlists, quotas, transaction limits and approval gates.
- Prompt, memory and output handling that treats all external content as untrusted.
- Model, dataset, embedding, platform and plugin provenance with change monitoring.
- Injection, hijacking, leakage, poisoning and output-validation evaluations tied to defined failure outcomes.
- Centralized logs, alert thresholds, incident playbooks and a tested rollback or shutdown path.
- Supplier commitments for notification, vulnerability handling, data use and service termination.
After launch, review permissions and data sources periodically, not only when the model changes. New tools, indexes, connectors and delegated agents can expand the attack surface even when the underlying model version is unchanged.
Which OWASP risk labels should appear in our threat model?
Use the labels as a shared vocabulary, then map each to your architecture: “Prompt Injection,” “Sensitive Information Disclosure,” “System Prompt Leakage,” “Supply Chain,” “Excessive Agency,” “Data and Model Poisoning,” “Improper Output Handling,” and “Vector and Embedding Weaknesses.” OWASP’s list also covers misinformation and unbounded consumption. Labels organize analysis; they do not substitute for system-specific evidence, authorization design or testing.
Also popular on Amazon
Frequently Asked Questions
Should an AI agent have its own login or service account?
Yes. Give each agent a distinct identity and credentials so permissions, approvals, logs and revocation are attributable to that agent. NIST’s December 2025 AI Cybersecurity Framework Profile is an initial preliminary draft, but it explicitly suggests treating agents with precautions used for privileged users.
Is encrypting prompts enough to prevent AI data leaks?
No. Encryption protects data in transit or storage, but an authorized model context, tool call or log can still disclose it. Combine encryption with data minimization, field-level authorization, redaction, egress inspection and strict telemetry retention.
Can retrieval-augmented generation make prompt injection impossible?
No. Retrieval can introduce untrusted instructions as well as useful facts, creating an indirect-injection path. Authenticate and filter sources, preserve provenance, isolate content from policy, and constrain any action that follows retrieval.
What evidence should we request from an AI vendor before approval?
Request model and dataset versions, supply-chain and subprocessor information, data-use and retention terms, security contacts, update and incident-notification processes, evaluation summaries, access-control design and rollback options. Require answers to be specific to the deployed configuration rather than broad claims about the model family.
Who should be allowed to approve an AI agent’s high-impact action?
The approver should be an accountable owner with authority over the affected data or process, not the model itself. Use separation of duties for sensitive operations, show the proposed parameters and data destinations, and record the decision and evidence for audit.
