Is your AI agent secure? 2026 permissions, prompt injection, and acceptance

The short answer: the main risk is not that an AI agent writes a wrong sentence. It is whether the agent can read data it should not, call tools it should not, or take actions that cannot be undone. OWASP 2025 highlights prompt injection, sensitive information disclosure, and excessive agency; least privilege, treating external content as untrusted, human approval for high-risk actions, complete logs, and a working stop switch are the shared baseline. This guide is for enterprise leaders evaluating or already running agents. Data cut-off: 25 October 2026. It is not a security certification or legal advice.

This is not a “which model is safer” review. It covers what changes when an agent is connected to a CRM, ERP, mailbox, knowledge base, and automation tools: permission design, attack testing in a POC, acceptance evidence, and contract terms. Public sources cannot prove that any company is “unhackable”, and they do not replace penetration testing, certification, or legal review.

How is agent security different from a chatbot?

A chatbot mainly generates text; an agent reads data and calls tools, so the risk expands from wrong content to privilege abuse, leakage, wrong actions, and supply-chain exposure.

A support bot that only answers questions can still be wrong or leak something it should not. An agent that can look up orders, change addresses, send email, update a CRM, or call an ERP API turns failure into a real business action: shipping to the wrong customer, sending internal pricing externally, deleting a file, duplicating a purchase order, or being manipulated by hidden instructions in an external document.

Agent security therefore has four layers: whether model output is trustworthy, whether tools are constrained, whether the identity has permission, and whether actions can be traced afterwards. Prompt hardening alone is a lock written on paper.

Editorial comparison, not a vendor product taxonomy. Actual risk depends on the data, tools, and autonomy granted to the agent.

What are the most common agent risks?

OWASP 2025 lists prompt injection, sensitive information disclosure, excessive agency, supply chain, data poisoning, misinformation, and resource abuse; privilege abuse and leakage are the most damaging for enterprises.

OWASP’s LLM Top 10 is a community risk list, not a certification, and the numbers are not a direct priority order. Start with three questions: what data can this agent reach, what tools can it call, and who is accountable when it fails. The table pairs common risks with controls that a POC can verify.

Risk names follow OWASP Top 10 for LLM Applications 2025; scenarios and controls are editorial. OWASP explicitly notes that RAG and fine-tuning do not fully mitigate prompt injection.

How should permissions and tools be designed?

Deny by default and grant only the data and tools needed for the task; separate read and write, require human approval for high-risk actions, and validate tool parameters in code rather than relying on the model.

Microsoft’s agent security guidance distinguishes interactive agents acting for a signed-in user, autonomous agents using their own identity, and an optional agent user account. In all cases, an agent should not share an administrator account. A safer pattern is a unique identity per agent, a named owner and lifecycle, task-scoped permissions, short-lived credentials, and authorization enforced by the downstream system rather than by the model.

Tool design should avoid open-ended capability. Do not give an agent a tool that can run arbitrary shell commands; if it must write a file, expose a narrow “write this file in this directory” tool. If it reads customer data, grant read-only access to the current customer and required fields, not the whole table.

These are editorial least-privilege examples, not a universal compliance requirement. Adapt to data classification, role, system, and impact; high-risk actions should not depend on model judgement alone.

How do we defend against prompt injection and poisoned knowledge?

Treat web pages, email, files, and retrieval results as untrusted; separate instructions from data, limit tool scope, filter output, and govern knowledge sources, versions, and approvals.

The key is not to make the model “more obedient”; it is to ensure that a deceived model still cannot do dangerous things. OWASP classifies both direct and indirect prompt injection as LLM01: attackers can hide instructions in web pages, PDFs, email, résumés, images, or retrieval results. RAG and fine-tuning can improve relevance, but they do not fully remove this risk.

Practical defenses include separating system instructions, user instructions, and external data; checking source and permissions at retrieval; validating tool parameters deterministically; encoding output and filtering sensitive data; requiring human approval for high-risk actions; and continuously testing with red-team cases. The 2025 CISA/NSA/FBI AI data security guidance also highlights the data supply chain, malicious modification, and data drift, recommending encryption, signatures, provenance, secure storage, and monitoring for data used to train and operate AI systems.

• Source: every knowledge document needs an owner, approval, version, and expiry; unknown sources do not enter production retrieval.
• Permission: filter at retrieval by user and customer; do not retrieve everything and ask the model not to tell.
• Isolation: external content is data, not instructions; keep tool execution separate from content parsing.
• Validation: check tool parameters in code; never concatenate model output directly into SQL, shell, or API calls.
• Monitoring: log retrieval source, document version, tool calls, and anomalies; enable rollback when poisoning is found.

What should logging, human approval, and incident response look like?

Log who used which agent, when, with what tool, data, and outcome; require approval for high-risk actions, allow a pause, and make incidents traceable and reversible.

Keeping the chat transcript is not enough. Capture the agent identity, initiating user, task, model and version, data sources read, tool name and parameters (redacted), approver, result, failure reason, and correlation ID. Write actions must preserve before/after values; cross-agent calls must show which upstream agent initiated them.

Put human approval where the risk is real: external sending, quotes/discounts, refunds/payments, deletion, permission changes, production parameters, and contractual commitments. The approval screen should show what will happen, who is affected, and which data is used — not just a “continue?” button. Also rehearse pause, credential revocation, agent isolation, and rollback.

“100% approval” is an editorial suggestion, not a universal standard; dual approval and exceptions should depend on reversibility and company policy.

How should the POC test security?

Run a four-to-six-week shadow POC on a real workflow, covering unauthorized reads, indirect injection, malicious files, loops, shutdown, and human takeover; record blocks and false positives.

A POC should not be “ask a question and the agent answers correctly”. Pick one real workflow (for example lead routing, quote drafting, or after-sales tickets), use 10–20 real tasks and three roles, and run both normal and attack cases. Keep the test environment separate from production; do not use destructive tests such as deleting production data, making real payments, or sending mass email.

POC design draws on OWASP adversarial-testing advice and Microsoft’s human-oversight/intelligibility principles; add cases for your workflow. Without real attack testing, do not claim prompt injection is “prevented”.

What should we ask vendors and put in the contract?

Ask about model/tool/data boundaries, permission model, log ownership, training use, vulnerability response, exit migration, and incident liability; an unevidenced “secure” claim is not enough.

Do not rely on a security whitepaper alone. Ask the vendor to map your data flow: where data comes from, where it is stored, who can access it, whether it is used for training, which subprocessors are involved, who owns logs, and how deletion is proven. For “we have certification”, ask about scope, version, expiry, and covered products; certification does not replace scenario-specific testing.

• Identity and permission: unique agent identity, least privilege, short-lived credentials, approval, and revocation?
• Data: is customer data used for training? How long is it retained? Can it be disabled? How are deletion and export verified?
• Tools and supply chain: inventory, versioning, signatures, and change notice for models, plugins, and MCP tools?
• Logs and audit: which fields, who owns them, retention, and integration with the enterprise SIEM?
• Vulnerability and incident: reporting, notification time, drills, containment, and root-cause report?
• Exit: data migration, deletion of copies, and continued use of historical records after termination?

Is Lingyi a fit?

If you need private deployment, internal data, tool permissions, and audit, Lingyi can provide the AI foundation and integration. For standard public SaaS features, a mature platform is usually the better first choice.

Lingyi does not issue security certifications and does not promise “zero risk”. If you need to connect agents to an internal ERP/MES, control model and data boundaries, and centralise identity, logs, and approvals, LingHarness can serve as a private AI foundation for model access, permissions, audit, and agent execution boundaries; LingWork covers internal office workflows. If you only need a standard SaaS agent, use the platform’s native permissions and audit controls first, which is usually cheaper.

Related reading: AI agent implementation guide, agent base comparison, agent operations metrics, agent regulation and compliance, and private deployment cost.

FAQ

These questions come from procurement and POC discussions; answers use public sources and editorial judgement, not penetration testing, certification, or legal advice.

Can prompt engineering make an AI agent secure?

No. Prompts can constrain behaviour, but OWASP notes there is no reliable complete prevention for prompt injection, and RAG or fine-tuning do not fully remove it. Layer tool allowlists, least privilege, parameter validation, human approval, logging, and adversarial testing.

Is private deployment always more secure?

No. Private deployment can improve data boundaries and network isolation, but if the agent still uses a shared admin account, has excessive tool permissions, or lacks logs, the risk remains. Security depends on identity, permissions, tools, data, and operations, not location alone.

Does an agent need its own identity?

Yes, preferably. A unique identity makes authorization, audit, revocation, and accountability easier, and prevents the agent from inheriting all permissions of an employee or administrator. Microsoft’s guidance treats unique agent identity, an owner, and lifecycle management as foundations for reducing agent sprawl.

Can an agent send email, quote, or place orders automatically?

It can draft or initiate a workflow, but high-ticket B2B should not send quotes, discounts, contract commitments, or orders without review. Use templates, limits, customer allowlists, human approval, idempotency, and revocation, and check opt-out, privacy, and frequency.

What is most often missed in a knowledge-base integration?

Source and permissions. A knowledge base can be poisoned by a malicious document or retrieve customer A’s data for customer B. Require document approval, version rollback, user/customer filtering at retrieval, and a record of which version supported each answer.

How do we judge a vendor’s security capability?

Ask for evidence, not slogans: data-flow diagram, permission matrix, log samples, scope and date of pen-test/red-team reports, vulnerability-response SLA, subprocessor list, and exit/deletion plan. Require a POC on your real workflow; a generic demo is not enough.

Sources, method, and limits

This is public-source research and editorial synthesis; it does not include interviews, penetration testing, or product testing. Sources include the OWASP community risk list, the voluntary NIST AI RMF generative-AI profile, joint CISA/NSA/FBI guidance, and Microsoft official documentation. They are not interchangeable and do not constitute certification, a compliance conclusion, or legal advice. Controls must be adapted to data classification, system boundaries, and business impact.

1. OWASP, Top 10 for LLM Applications 2025 (LLM01 Prompt Injection; LLM06 Excessive Agency): https://genai.owasp.org/llm-top-10/; LLM06 detail. Accessed 25 Oct 2026.
2. NIST, AI Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), 26 July 2024: official page. Voluntary framework.
3. CISA, NSA, FBI and international partners, AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems, 22 May 2025: official page.
4. Microsoft Learn, Microsoft Entra security for AI overview, document date 8 May 2026, updated 14 Aug 2026: official documentation.
5. Microsoft Learn, Reduce autonomous agentic AI risk, 19 Mar 2026: official documentation.

The Chinese version is at 企业 AI Agent 安全与验收清单.