AI agent security in 2026: a practical CISO guide
A field guide for governing agentic AI across coding tools, homegrown agents, computer-use systems, and SaaS platforms without stopping adoption.
The hard part is no longer deciding whether employees will use agents. It is creating a control model that follows every agent from intent to action, across every place the business lets it work.
The shift from assistants to operators
Chatbots produced text. Agents read files, call APIs, use browsers, run shell commands, change records, and continue working through multi-step plans. That difference turns an AI policy question into an operational security question. A useful agent needs access, but every permission that makes it useful also enlarges the damage a mistake or manipulated instruction can cause.
NIST's 2026 analysis of AI agent security responses found broad agreement that agent risks are a real barrier to adoption and that existing cybersecurity practices need adaptation. The adjustment is not to abandon identity, least privilege, change control, or audit. It is to apply those controls to software that reasons probabilistically and can choose a sequence of actions you did not enumerate in advance.
An agent is not risky because it is intelligent. It is risky because intelligence is connected to authority.
Start with the four agent estates already forming
Most organizations do not have one agent platform. They have several estates growing at different speeds. Developers adopt Claude Code, Codex, Cursor, OpenCode, and similar coding agents on endpoints. Product teams build agents with LangChain, LangGraph, CrewAI, or internal frameworks. Business teams activate agents inside Salesforce, Microsoft, Google Cloud, and other SaaS systems. Computer-use agents add a fourth category by operating ordinary interfaces through clicks and keystrokes.
Each estate has useful native controls, but the security model is fragmented. A CISO may have strong Microsoft policies, a carefully configured Salesforce environment, and a disciplined cloud platform, while a local coding agent can still read a developer's home directory or call a newly installed MCP server. Inventory has to cross product boundaries or it will describe only the agents the security team already knows about.
- Endpoint and vibe-coding agents with filesystem, terminal, Git, and browser access
- Homegrown agents with custom tools, memory, queues, and framework-specific orchestration
- Computer-use agents that act through graphical interfaces instead of stable APIs
- SaaS and cloud agents that inherit platform identities, data, connectors, and policies
Build the threat model around reach and consequence
A model name is not a threat model. Ask what the running agent can see, which identity it uses, which tools it can invoke, where its instructions originate, what it remembers, and whether an action can be stopped before execution. Two agents using the same model can have radically different risk. One summarizes public documents. The other can query customer data, edit a deployment, and send email as an employee.
The most useful unit of analysis is a proposed action with context. A database delete, external publish, credential read, payment, infrastructure change, or bulk customer message deserves more scrutiny than a file search or test run. This makes the policy legible to the business because it connects autonomy to consequences instead of treating every prompt as equally dangerous.
- Identity: who or what is the agent acting as?
- Reach: which files, services, databases, browsers, and networks can it access?
- Intent: what goal and instructions produced this action?
- Consequence: can the action expose data, spend money, publish, delete, or change production?
- Reversibility: can the action be undone, and how quickly?
- Evidence: will the business have a durable record of what happened?
Use layered controls, but enforce at the last responsible moment
Model safeguards, secure prompts, sandboxing, identity controls, data policies, network boundaries, and vendor governance all matter. None should be asked to carry the entire risk. Models are probabilistic. Sandboxes cannot cover every SaaS action. Identity systems confirm who may call an API but usually do not understand why an agent is calling it. Human review becomes ineffective when people approve a constant stream of low-value prompts.
The missing layer is real-time protection. Intercept the action, understand what it could affect, and make a clear decision before it runs. That is the moment when the agent's goal, the data involved, and the possible consequence can be judged together.
A risk-tier model that does not kill velocity
Trying to approve every action is a fast route to bypasses and approval fatigue. Tier the agent, environment, and action. Let reversible reads and changes inside a bounded workspace move quickly. Add monitoring for actions that touch broader data or external systems. Require explicit review for destructive, externally visible, financially material, or high-volume actions.
Risk tiers should describe the action, not the prestige of the employee or vendor. A trusted agent can misunderstand a trusted user. A secure platform can still be configured with excessive permissions. The purpose of tiers is to create predictable decision rights that remain useful when the model, framework, or SaaS platform changes.
- Tier 0: observe-only tasks with no write or external side effects
- Tier 1: reversible work inside a bounded project or test environment
- Tier 2: access to sensitive data, connected services, or external publishing
- Tier 3: destructive, production, financial, identity, or bulk communication actions
Where Leash fits
Leash is the safety layer across the agents people actually use. It intercepts supported actions, detects destructive commands, protects secrets, ignores hidden instructions, applies selected rules, and gives people a clear decision. Where an AI platform only shares activity afterward, Leash provides honest visibility instead of pretending it could have stopped the past.
Individuals can keep Personal Open Source on their own machine and use their own model-provider key. Personal Leash Cloud offers a managed path at $8 per month. Business Leash Cloud costs $18 per user each month, or $14 with annual billing. Desktop apps support macOS and Windows, while web and optional iOS or Android alerts keep approvals connected to the request that created them.
Leash does not replace identity, sandboxing, or vendor controls. It adds the action-aware layer those systems do not consistently provide across agents.
A focused 90-day program
In the first month, inventory agent categories, owners, identities, connected tools, data classes, and high-consequence actions. In the second month, instrument a narrow but representative group, such as developer coding agents and one customer-facing SaaS agent. Measure actions, false positives, approval volume, and the controls employees try to bypass. In the third month, turn the observed patterns into risk tiers and expand by use case.
The outcome should not be a giant policy document. It should be a living control loop: know which agents exist, understand what they can reach, enforce the few actions that matter most, give a human enough context to decide, and preserve evidence for learning and response. That is how agent adoption becomes a managed capability instead of a permanent exception process.