Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to secure AI agents?

Securing an AI agent means controlling what data it can see, what actions it can take, and who answers for each consequential step, with controls placed outside the model as well as inside it. Get one of the three wrong and a persuaded, rushed or mistaken model becomes an incident: a record disclosed, a payment released, a permission granted.

Enterprise records pass access controls into an isolated computing module before approved delivery.

Securing an AI agent means controlling what data it can see, what actions it can take, and who answers for each consequential step, with controls placed outside the model as well as inside it. Get one of the three wrong and a persuaded, rushed or mistaken model becomes an incident: a record disclosed, a payment released, a permission granted. An agent is not only a model. It is a model joined to tools, credentials, memory, and content from the open environment, and each of those joins is a place where an instruction, a secret, or a permission can cross a boundary it should not cross. The control sequence below is drawn from public frameworks: inventory the agent, limit its exposure, separate instructions from data, gate consequential actions, and keep a record that a person can review after the fact. The exposure limit is the principle of Least Exposure: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Prompt injection is ranked first among risks for LLM applications, and indirect injection through retrieved content is treated as a core variant, not an edge case (OWASP, 2025).
  • Excessive agency is a distinct listed risk: harm grows when an agent holds more tools, permissions, or autonomy than its task requires (OWASP, 2025).
  • The NIST AI Risk Management Framework organizes AI risk work into four functions, Govern, Map, Measure, and Manage, which give an agent program an owner, a context, a test method, and a response path (NIST, 2023).
  • Zero trust guidance grants access per session, on dynamic policy, with authentication and authorization enforced before access, a pattern that fits short lived agent tasks better than standing access (NIST, 2020).
  • Joint guidance on agentic AI advises starting with lower risk tasks, applying least privilege, and retaining human oversight for high impact or irreversible actions (CISA, 2026).
  • Data minimization before the model reads anything reduces what a successful injection can collect, because the model cannot disclose values that never entered its context; OWASP lists sanitization before model input among the mitigations for sensitive information disclosure (OWASP, 2025).

What makes an AI agent different from a chatbot to secure?

A chatbot mainly produces text. An agent produces effects. It can open pages, read records, call tools, move between applications, and in some designs send messages, change records, or start payments. That difference changes the security question from whether an answer is correct to whether an action was authorized, proportionate, and reversible. The OWASP list captures the shift by treating improper output handling and excessive agency as separate risks from the quality of the text itself (OWASP, 2025). If model output flows unchecked into a downstream system, a wording problem becomes a system problem.

Agency also multiplies principals. The agent serves a user, follows developer instructions, reads content written by third parties, and acts through tools owned by other teams. When those inputs disagree, the model has no reliable built in method for deciding whose instruction should win. OWASP notes that models do not consistently separate instructions from data, which is why a security design should assume confusion is possible and limit the damage that confusion can cause (OWASP, 2025). Securing the agent therefore means securing the environment around it: the data it is shown, the tools it can reach, and the point at which a human must decide.

Where do agent attacks actually enter?

The first entry point is direct input, where a user tries to make the agent ignore its instructions, reveal its system prompt, or use a tool for an unintended purpose. The second, and for browser and research agents often the larger one, is indirect input: instructions hidden in a web page, a document, an email, a ticket, or a retrieved record. OWASP classifies prompt injection as LLM01 and describes both direct and indirect forms (OWASP, 2025). An agent that browses for a living reads untrusted content as part of normal work, so filtering user input alone leaves the main channel open.

A third entry point is the tool and supply chain layer. Plugins, connectors, model providers, and data sources all extend what the agent trusts. The NIST Generative AI Profile lists value chain and component integration, information security, and data privacy among its twelve risk categories for generative AI (NIST, 2024). A fourth entry point is memory and retrieval. If an agent reuses notes, embeddings, or prior outputs across users or tasks, one session can contaminate another. OWASP treats vector and embedding weaknesses as their own risk for this reason (OWASP, 2025). Across all entry points, treat every input as untrusted until a control outside the model has decided what it may influence.

How should identity and permissions be scoped for an agent?

Give the agent its own identity, separate from the identity of the person who asked for the work. Shared human credentials make logs ambiguous, make revocation disruptive, and give the agent the full reach of a person even when the task needs a fraction of it. Joint agentic guidance recommends distinct identities for agents and continuous authentication of agent interactions (CISA, 2026). A distinct identity lets a team scope, monitor, and withdraw agent access without touching the accounts of staff.

Scope should then follow the task, not the job title. Zero trust architecture grants access to a resource on a per session basis and decides access through dynamic policy that can consider identity, device, and context (NIST, 2020). Applied to an agent, that means short lived credentials issued for one run, limited to the applications and records that run requires, and expiring when the run ends. Standing access to a whole drive, inbox, or customer database fails that pattern even if the agent is well behaved on an average day.

Least privilege also applies to tools. An agent that only needs to read should not hold a write tool. An agent that needs to draft should not hold a send tool. OWASP advises minimizing the extensions an agent can call, minimizing the functionality inside each extension, and requiring human approval for actions with side effects (OWASP, 2025). Those three moves together turn a vague instruction to be careful into an enforceable boundary.

How do you keep sensitive data out of model context?

The most dependable disclosure control is the one applied before the model reads anything. Once a password, account number, health detail, or customer record has entered model context, later controls are trying to catch it on the way out, in output, in logs, or in memory. OWASP lists sensitive information disclosure as LLM02 and points to sanitization and access control as mitigations (OWASP, 2025). Prevention at the input side is stronger than inspection at the output side because it does not depend on recognizing every form a leak could take.

Practical methods differ by layer. At the data layer, retrieve only the fields a task needs and apply the requesting person's permissions before retrieval, not after generation. At the prompt layer, keep secrets out of system prompts entirely, since OWASP warns that system prompts should not carry credentials or authorization logic (OWASP, 2025). At the screen layer, for agents that work through rendered applications, replace sensitive values with tokens before the screen is read, so the agent can complete a workflow by position and label without holding the underlying value. At the logging layer, redact prompts and outputs before storage, because logs become a second copy of everything the agent saw.

Classification helps but does not finish the job. NIST guidance on de-identifying datasets describes masking and replacement for direct identifiers, and warns that repeatable transformations can raise re-identification risk if handled carelessly (NIST, 2023). Choose the transformation for the task: mask what never needs recovery, tokenize what must be resolved later at an approved destination, and leave out what the task does not need.

How should tools and consequential actions be controlled?

Separate drafting from doing. Many agent failures become incidents at the moment a prepared action is executed without a separate check: a payment released, a message sent, a record overwritten, a permission granted. A control gate at that moment, staffed by a named person who sees what is about to happen, converts an autonomous error into a reviewed decision. Joint agentic guidance advises retaining meaningful human oversight over high impact or irreversible actions and expanding autonomy only as controls mature (CISA, 2026).

The gate needs substance to work. The approver should see the destination, the amount or record involved, and the source the agent relied on, in plain form rather than as a model summary alone. Approvals should be per action, not a blanket setting that persists across runs. Rate limits, value limits, allow lists of destinations, and time windows add a mechanical layer beneath the human one. Model output treated as code, markup, a query, or a tool argument should also be checked by the receiving system as untrusted input (OWASP, 2025).

Action type Example Sensible default control
Read only Look up an order status Scoped identity, logged access
Draft Prepare a reply or a form entry Human review before use
Record change Update an address or a status Named approval at the moment of change
Money movement Pay an invoice or issue a refund Named approval plus value limits and destination checks
Access change Grant a user new permissions Named approval, separate from the requester where policy requires

How do you monitor, test, and respond when an agent misbehaves?

Logging is the control that makes the others auditable. A useful agent log records the task, the policy in force, the screens or sources read in tokenized form, each tool call, each approval with the approver name, and the final outcome. NIST frames monitoring and incident response inside the Manage function of the AI Risk Management Framework, alongside prioritizing and treating risk (NIST, 2023). Without that record, a team cannot tell whether an incident came from an injection, a mis-scoped permission, or a simple model error, and each cause needs a different fix.

Testing should match the attack surface described earlier. Red team exercises should include indirect injections placed in pages and documents the agent will read, attempts to extract system prompts and credentials, cross session retrieval tests, and tool misuse tests where the agent is pushed toward an action outside its task. The Generative AI Profile recommends testing and evaluation across the lifecycle rather than only before launch (NIST, 2024). Findings should feed back into scopes and gates, not only into prompt wording, because prompt changes are the weakest layer to rely on.

Response planning completes the sequence. A team should be able to revoke an agent identity, pause a workflow, and preserve its logs, and should decide in advance who can do each thing. Start with a narrow, low risk workflow, review its records, and widen scope only when the evidence supports it (CISA, 2026).

Where does RedactSure sit?

RedactSure is that sequence implemented as a working design rather than assembled control by control. Its supervised AI co-workers complete browser workflows across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions. Render-layer tokenization keeps policy-selected values out of model context: every identifier chosen by policy is replaced by a consistent token before any model reads the screen, so the model receives the task's fields with SSN_001 and ACCT_001 in place of the real values, and real values resolve only at approved destinations at the moment of an approved action.

Supervised Delegation means a named person confirms the Planner policy before the run and approves each consequential action as it happens; the agent prepares the payment, submission or record change, and the person releases it. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM, which is the reviewable record the last step of the sequence asks for. Keys stay with the customer and the model is swappable. Deployments are in pilot. Controls placed around the model this way hold even when the model is persuaded, rushed, or wrong. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page rests on public primary and standards sources, read as of October 13, 2026: the NIST AI Risk Management Framework (AI RMF 1.0, 2023) and its Generative AI Profile (NIST AI 600-1, 2024), both official guidance; NIST SP 800-207 on zero trust architecture (2020) and NIST SP 800-188 on de-identifying government datasets (2023), both standards publications; the OWASP Top 10 for LLM Applications 2025, an industry standard, cited from its individual risk entries; the 2026 joint agency guidance on careful adoption of agentic AI services led by CISA; and the 2023 CISA and NCSC Guidelines for Secure AI System Development. Where a source ranks a risk, the ranking is reported as that source's own.

No agent product was tested, no penetration test was run, and no benchmark is reported. No hands-on testing of any named vendor product was performed. Controls are described at the level the sources support; implementation details, and whether a given deployment configures a control correctly, are outside the scope of a desk review. No statistic about attack frequency is asserted, because the sources rank and describe risks without supplying a single rate that applies across agent types. Framework editions and vendor features change; the page carries its date and is revised when a cited source is updated. The order status, refund and permission examples describe action types, not any organization; no customer or prospect is described.

Whether a control sequence meets an organization's requirements belongs to its counsel, its assessor and its own security and compliance officers, not to this page. The frameworks cited set out functions and risks; mapping them to a specific agent, application and data set is the organization's determination.

What the record shows

Securing an AI agent is boundary work. The model sits at joins to tools, credentials, memory, and content from an open environment, and each join decides whether an instruction, a secret, or a permission crosses somewhere it should not. The sequence follows those joins: inventory the agent, scope its identity and permissions, keep sensitive data out of model context, separate instructions from retrieved data, gate consequential actions behind a named person's approval, and keep a reviewable record. An agent whose controls live only in its prompt fails at the moment the prompt is overridden. The test to apply is to ask, for one workflow, what the model received, who approved each consequential action, and where the record of both can be read.

Frequently asked questions

What is the first step in securing an AI agent?

Inventory, before any control is tuned. A team needs to know the agent exists, what it connects to, whose credentials it uses, what data it can reach, and who owns it, because every later decision about privilege, monitoring, and approval depends on that picture. The NIST framework's Map function exists for this stage, and joint guidance makes the same point operationally: agents that are not listed cannot be scoped, tested, or retired, so discovery is a security control in its own right.

Why place controls outside the model instead of training it to behave?

Because the model's judgment is one of the things under attack. Content the agent reads can carry instructions, and a control that depends on the model noticing and refusing them fails exactly when the model is successfully persuaded. External controls do not ask the model's permission: a permission boundary refuses the action, a token replaces the sensitive value before reading, and an approval step waits for a person. Training and prompting still help, but they are the layer most exposed to the threat.

What record should an agent deployment keep?

A record a person can review after the fact, covering what the agent was asked to do, what it read, which tools it called, what it changed, and who approved each consequential step. The NIST framework and the joint agency guidance treat logging and monitoring as the evidence base for incident response and for the Measure and Manage work of the lifecycle. A record that captures only final answers leaves the team unable to say how a result was produced, which is the first question after anything goes wrong.

Should an AI agent use its own identity or the user's credentials?

Its own identity. Shared human credentials make logs ambiguous, make revocation disruptive, and give the agent a person's full reach when the task needs a fraction of it. Joint agentic guidance recommends distinct identities for agents and continuous authentication of agent interactions. Scope then follows the task: short lived credentials issued for one run, limited to the applications and records that run requires, and expiring when the run ends, as zero trust guidance describes for per session access.

Which agent actions should require a named person's approval?

Any action with a side effect the team would want reviewed: a record change, a payment or refund, a message sent to a customer, or a permission granted. Read only lookups need a scoped identity and a log. Drafts need human review before use. The approver should see the destination, the amount or record, and the source the agent relied on, in plain form, and approvals should be per action rather than a standing setting that persists across runs.

Can prompt injection be fixed by writing a better system prompt?

No. Prompt wording is the weakest layer to rely on, because OWASP notes that models do not consistently separate instructions from data, and an injected instruction arrives through the same channel as the prompt. The durable fixes sit outside the model: keep sensitive values out of context so an injection has nothing to collect, limit the tools the agent can call, treat model output as untrusted input, and gate consequential actions behind a person. Red team tests should place injections in the pages and documents the agent will read.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.