Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to secure AI Agents in Enterprise?

At enterprise scale the answer is a program built on an agent inventory with named owners, central policy with local task scoping, and records an auditor can review. Without that program, two teams can run the same model at very different risk while both describe themselves as following policy, and no one can show who approved what.

Enterprise task cards cross a configurable control gate before entering an activity ledger.

At enterprise scale the answer is a program built on an agent inventory with named owners, central policy with local task scoping, and records an auditor can review. Without that program, two teams can run the same model at very different risk while both describe themselves as following policy, and no one can show who approved what. Securing AI agents in an enterprise adds scale, ownership, and audit to the basic agent problem: many teams, many applications, shared data, and regulators or customers who will ask who approved what. The answer is a program, not a single tool. An organization needs an inventory of agents, a named owner for each deployment, central policy with local task scoping, identity and data controls that work across existing systems, and records that can be produced for review. Those records are what an AI Control Record holds: every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. Public frameworks written for enterprise risk and for zero trust architecture show how the program elements fit together. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Enterprise AI governance needs an accountable structure, not only technical controls. The Govern function of the NIST AI Risk Management Framework covers policies, roles, and accountability across the other functions (NIST, 2023).
  • A central inventory is a precondition for control: an enterprise cannot scope, monitor, or retire agents it has not listed, including agents bought inside business units (CISA, 2026).
  • Zero trust design replaces network location with per session, policy based decisions, which lets the same agent rules apply across cloud, office, and remote settings (NIST, 2020).
  • Supply chain and component risk is an enterprise level concern for generative AI, covering model providers, plug-ins, and data sources as well as internal code (NIST, 2024).
  • Human oversight for high impact actions, continuous logging, and progressive rollout from lower risk tasks are recurring recommendations in joint agency guidance on agentic AI (CISA, 2026).
  • Sensitive information disclosure remains a top listed risk, so enterprise data classification and minimization programs should extend to agent context, prompts, and logs (OWASP, 2025).

What changes when agents move from a pilot to the enterprise?

A pilot has one team, one workflow, and people who remember why choices were made. An enterprise deployment has none of those protections by default. Agents appear in different departments, built on different models, connected to the same underlying records. A permission granted for a finance pilot can matter for a human resources workflow if both agents reach the same system of record. Risk therefore becomes a property of the portfolio, not only of each agent in isolation.

Consistency is the second change. In a pilot, an approver may know the agent habits. At scale, approval quality depends on standards: what an approval screen must show, which actions always require approval, which destinations are allowed, and how long credentials live. Without those standards, two teams can run the same model with very different risk and both describe themselves as following policy. The NIST AI Risk Management Framework is built for this problem: its Map function establishes context for each system, its Measure function tests risk, and its Manage function prioritizes treatment, all under a Govern function that sets culture and accountability (NIST, 2023).

Who should own agent security, and what policy should exist?

Ownership should be shared but not diffuse. A central function, usually security with risk and legal input, sets baseline policy and maintains the inventory. A named business owner for each agent answers for its purpose, its data, and its approvers. A technical owner answers for configuration and change. That split mirrors the cross-discipline model used in other risk programs: NIST SP 800-53 describes an insider threat program with a cross-discipline incident handling team and a designated senior official providing oversight (NIST, 2020). The point is not the committee itself. The point is that no single team sees only the convenient part of the risk.

Enterprise policy should state, in writing, a short list of enforceable rules. Which data classes may enter model context, and which may not. Which actions always need a named human approval. Which agent identities may hold write access, and for how long. How long logs are kept, and where they are sent. Which models and providers are approved, and what review a new provider requires. The Generative AI Profile can help structure the risk side of that policy, since it names data privacy, information security, human-AI configuration, and value chain risks as distinct categories to address (NIST, 2024).

How does an enterprise inventory and approve agents before use?

An inventory entry should read like a control record, not a marketing list. For each agent, record its owner, purpose, model and provider, tools and connectors, applications reached, data classes read and written, credential type and lifetime, approval gates, log destination, and retirement date or review date. Joint guidance on careful adoption of agentic AI recommends maintaining a clear inventory of agent capabilities and dependencies (CISA, 2026). Dependencies matter because a change in a connected application or a model provider can change agent behavior without any internal change being made.

Approval before use should be proportionate. A read only agent working on public data needs a light review. An agent that can write to customer records, handle payment data, or act across departments needs a full review, including threat modeling for prompt injection, testing with adversarial content, and a check that its permissions match its task. OWASP recommends designing on the assumption that prompt injection may succeed, and limiting the privileges and autonomy that an injected instruction could exploit (OWASP, 2025). Approval should therefore test blast radius, not only test whether testers could break the prompt on the day.

Re-approval triggers are as important as first approval. A new tool, a new data class, a new model, a wider user group, or a move from drafting to executing should return the agent to review. Treat those changes the way change management treats a new integration, because functionally that is what they are.

How should access work across many applications and teams?

The enterprise pattern that fits agents best is central policy with per task enforcement. NIST zero trust architecture separates the policy decision point, which decides access from policy and context, from the policy enforcement point, which enforces that decision close to the resource (NIST, 2020). For agents, central teams can define who and what may act, while enforcement in each workflow checks the specific run, the specific record, and the specific action before allowing it.

Identity discipline carries most of the weight. Each agent should authenticate as itself, with credentials scoped to its task and rotated or expired automatically. Human single sign on should not be inherited silently by an agent acting hours later on a different task. Where an agent acts on behalf of a person, that delegation should be explicit, bounded, and recorded, so a later reviewer can separate what the person authorized from what the agent chose. CISA and partner agencies advise strong identity and access management for agents, including distinct identities and continuous authentication of interactions (CISA, 2026).

Segregation of duties still applies. The team that builds an agent should not be the only team that approves its consequential actions, and an agent that prepares a payment should not be the control that releases it. Existing enterprise controls, such as access reviews, joiner and leaver processes, and privileged access management, should include agent identities in their scope rather than treating agents as ordinary software.

How do data controls scale without rebuilding every application?

Enterprises rarely get to rebuild the application estate around agents. Agents are added to systems that already hold customer, financial, and employee data, often through the same screens staff use. Data control therefore has to work at the points the agent actually touches: retrieval, screen reading, tool calls, output, and logs.

A scalable sequence starts with classification the organization already has. If data classes exist for records, extend them to agent context: which classes may be retrieved, which must be transformed first, and which must never enter a prompt, a screen read, or a log. OWASP lists sensitive information disclosure as LLM02 and recommends sanitizing data and restricting what a model can retrieve for a given user (OWASP, 2025). Retrieval checks should enforce the requesting person permissions before content reaches the model, so the agent cannot become a route around existing access control.

Transformation is the next layer. Masking suits values that only need to be recognized, such as showing the last part of an account number for matching. Tokenization suits values an approved process must resolve later. NIST de-identification guidance sets out masking and replacement options for direct identifiers and cautions about repeatable transformations and re-identification risk (NIST, 2023). At browser level, transforming values at the render layer, before a screen is read, avoids per application rework because the control sits where the agent sees the application, not inside each application code base.

Finally, protect the copies. Prompts, traces, and exports are enterprise data too. Set retention and redaction rules for agent logs, and send security relevant events to the central SIEM.

How are monitoring, audit, and incidents handled at enterprise scale?

Central monitoring should collect a common event shape from every agent: task, owner, policy version, inputs in protected form, tool calls, approvals, outcomes, and errors. Common shape matters more than volume. An analyst should be able to compare two agents, or the same agent before and after a change, without learning a new log format each time. NIST zero trust guidance treats collecting information about assets and communications and using it to improve posture as one of its core tenets (NIST, 2020).

Audit questions should be rehearsed before an auditor or a customer asks them. Can the enterprise show which agents touched a given customer record last quarter? Can it show who approved a specific agent action, and what that approver saw? Can it show that a retired agent credentials were revoked? If any answer requires asking the original developer, the record design needs work.

Incident handling should include agent specific steps in the existing plan: revoke the agent identity, pause connected workflows, preserve logs and prompts, check whether other agents share the same connector or credentials, and review actions the agent took in a defined look back window. Tabletop exercises that include an injected instruction in a routine document are more useful for agents than generic phishing scenarios, because they test whether gates and logs work when the model itself has been misled.

Program element Minimum enterprise evidence
Inventory Owner, purpose, tools, data classes, review date for each agent
Policy Written rules on data, approvals, credentials, and approved providers
Access Distinct agent identities, per task scope, access reviews that include agents
Data Classification applied to context, screens, output, and logs
Oversight Named approval for consequential actions, central log and SIEM export
Response Revocation and pause procedure tested in an exercise

Where does RedactSure sit?

RedactSure supplies the runtime layer such a program needs across a mixed estate. Supervised AI co-workers run browser workflows across existing applications as rendered, with no per application integration for each new tool a team adopts, and no change to user permissions. One policy model travels with the work: every identifier chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, so the model receives the task's fields with ACCT_001 and SSN_001 in place of the real values, and real values resolve only at approved destinations at the moment of an approved action. The Planner sets tokenization and permitted actions per screen, and a named person confirms that policy and approves each consequential action under Supervised Delegation. The AI Control Record exports every screen as tokens, every action and every approval to the enterprise SIEM, giving central governance a single auditable record instead of per team reconstructions. Keys stay with the customer, and the model is swappable without moving the controls. Deployments of this design are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on enterprise oriented primary sources, all read as of October 13, 2026: the NIST AI Risk Management Framework (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-53 Revision 5 (2020) for program control structure, both standards; NIST SP 800-188 on de-identification (2023), official guidance; the OWASP Top 10 for LLM Applications 2025 entries LLM01 and LLM02, an industry standard; and the joint agency guidance on careful adoption of agentic AI services led by CISA (2026), official guidance. Each source is cited for the control it describes, with the date of the edition read.

The page does not survey enterprises, measure adoption, or test any vendor platform. No hands-on testing of any named product was performed, and no competitor product is described. Vendor features and agency guidance change; the page carries its date and is revised when a cited edition changes. Program recommendations are presented as control design, not as legal advice. The finance, human resources, customer record and payment examples describe workflow types, not any organization; no customer or prospect is described. Where a source describes a general control, the agent application of that control is stated as analysis, not as a claim that the source named that product or design.

Sector rules, employment law, and privacy obligations vary by jurisdiction and are not assessed here. Whether a program meets an organization's requirements, and whether any control satisfies a regulator or an auditor, belongs to its counsel, assessor, and its own security and compliance officers, not to the page.

What the record shows

At enterprise scale, agent security becomes a program property rather than a property of any single deployment. Many teams, many applications, shared data, and external parties asking who approved what require a central inventory, a named owner for every deployment, central policy teams can scope to their tasks, and records produced for review instead of reconstructed after an incident. Without that program, each team builds its own controls, the gaps between teams go unseen until an auditor finds them, and a retired agent's credentials can outlive the agent. The test is one question: pick any agent on the inventory and show who owns it, what it may see, who approved its last consequential action, and what that approver saw. If the answer requires asking the original developer, the program is not yet in place.

Frequently asked questions

Who should own AI agent security in an enterprise?

Two levels of ownership have to exist at once. The Govern function of the NIST framework expects an accountable structure covering policies, roles, and accountability for the whole program, and every individual deployment also needs a named owner who answers for its purpose, permissions, and record. A central team without deployment owners cannot judge task level risk; deployment owners without a central program reinvent controls inconsistently and leave gaps an auditor will find between teams.

Why is a central inventory a precondition rather than paperwork?

Because every later control is addressed to entries on that list. Scoping assumes the enterprise knows an agent's purpose and owner; monitoring assumes its activity can be recognized; retirement assumes it can be found and switched off. Agents bought inside business units are the standard failure, useful to one team and invisible to the program. Joint guidance treats inventory as a starting control for this reason, and no amount of downstream tooling compensates for an incomplete list.

How do data controls scale across many applications without rebuilding each one?

By attaching control to shared layers instead of to applications. The approach the frameworks support is to extend what already scales: identity decisions made per session under central policy, and the enterprise's classification and minimization programs carried into agent context, prompts, and logs. An application then inherits rules from the identity and data layers it already uses, instead of each team engineering agent specific handling inside every workflow. New applications join a governed pattern rather than starting a new negotiation.

What should an enterprise agent inventory record for each agent?

Owner, purpose, model and provider, tools and connectors, applications reached, data classes read and written, credential type and lifetime, approval gates, log destination, and a retirement or review date. Dependencies belong on the entry because a change in a connected application or a model provider can change agent behavior without any internal change. The entry should read like a control record an auditor can check, not a list of what the agent is for.

When should an approved agent go back through review?

When anything that changes its blast radius changes: a new tool, a new data class, a new model or provider, a wider user group, or a move from drafting to executing. Each of those is functionally a new integration and should be treated the way change management treats one. A re-approval checks that permissions still match the task and that an injected instruction could not exploit the new capability.

What belongs in an incident plan for AI agents?

Agent specific steps added to the existing plan: revoke the agent identity, pause connected workflows, preserve logs and prompts, check whether other agents share the same connector or credentials, and review the actions the agent took in a defined look back window. The plan should be exercised with a tabletop that plants an injected instruction in a routine document, because that tests whether the gates and logs hold when the model itself has been misled.

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.