Why this matters now
Organizations are beginning to use AI agents for activities that extend beyond generating or summarizing information. Depending on how they are configured, agents can retrieve sensitive data, call APIs, modify records, generate code, initiate workflows, and perform actions across business systems.
This creates a material change in risk. A chatbot generally recommends an answer; an AI agent may be authorized to act on it.
NIST recently reported broad agreement among respondents to a federal request for information that AI agents present novel security threats. Respondents also agreed that existing cybersecurity principles remain relevant but require adaptation for agent security. NIST’s analysis of AI-agent security
The practical question for leadership is therefore not whether every AI agent can be made perfectly secure. It is whether the organization can make each agent appropriately governed, access-controlled, monitored, recoverable, and cost-effective for its intended business purpose.
Executive takeaway
AI agents should be governed as a new class of digital operator.
They combine characteristics of software applications, service accounts, automation platforms, and delegated workers. Treating them as ordinary productivity tools can lead to excessive access, limited accountability, and actions that are difficult to reconstruct or reverse.
The immediate priority is not to purchase an entirely new AI security platform. Organizations should first reuse and extend existing identity, access-management, logging, change-management, data-classification, incident-response, and assurance capabilities.
This approach provides several quick wins:
- Inventory production AI agents.
- Assign business and technical owners.
- Give each agent an independent identity.
- Limit access and permitted actions.
- Require approval for consequential or difficult-to-reverse activities.
- Record the agent’s inputs, tool calls, decisions, and actions.
- Establish a tested method to suspend the agent and revoke its access.
These measures are generally more risk-justified and cost-justified than beginning with a complex, standalone AI governance platform.
What has changed
The first phase of enterprise generative AI largely focused on assisting people. Employees used models to draft documents, summarize information, search internal knowledge, or help analyze data.
Agentic systems introduce a different operating model. An agent may be able to:
- Search internal repositories
- Access customer or employee information
- Query financial and operational systems
- Create or update service tickets
- Generate and execute code
- Send messages or notifications
- Change system configurations
- Coordinate tasks across multiple applications
The underlying model is only one component of this architecture. The complete risk includes the agent’s instructions, memory, connected data, tools, credentials, orchestration logic, approval workflow, infrastructure, and human oversight.
As a result, evaluating only the model provider does not provide sufficient assurance. A well-protected model connected to an overprivileged identity or poorly controlled API can still create an unacceptable business risk.
Why fixed guardrails are insufficient
Policies, system instructions, content filters, and predeployment testing remain useful. However, leadership should be cautious about treating any of them as permanent assurance.
NIST published research in June 2026 explaining why a finite set of AI guardrails cannot be universally robust against adaptive adversarial prompts. The recommended response includes continuous adversarial testing, continued updates to defensive controls, and operational resilience designed to limit impact and support recovery. NIST’s continuous-monitor-and-update analysis
This does not mean that AI agents cannot be used responsibly. It means their security must be actively managed throughout their lifecycle.
An agent’s effective risk can change when any of the following changes:
- The underlying model
- System instructions
- Connected tools or APIs
- Available data
- Identity permissions
- Retained memory
- Business process
- Approval requirements
- External operating environment
Organizations therefore need a defined threshold for determining when a change requires renewed testing or approval.
Business requirements through a SABSA lens
The following attributes describe the most important business outcomes for an AI-agent security architecture.
| SABSA attribute | Business requirement |
|---|---|
| Governed | Each agent has an approved purpose, accountable owner, risk classification, and defined operating boundaries. |
| Authorized | The agent performs only actions explicitly approved for its business function. |
| Access-controlled | Data and system access follow need-to-know and need-to-access principles. |
| Integrity-assured | Agent instructions, context, tool calls, and outputs are protected from unauthorized manipulation. |
| Monitored | Material activity is logged and evaluated for abnormal or prohibited behavior. |
| Change-managed | Significant changes to models, permissions, tools, and instructions trigger review. |
| Assessed | Security and business controls are tested before deployment and periodically thereafter. |
| Recoverable | Access can be revoked quickly, actions can be investigated, and reversible changes can be restored. |
| Risk-managed | Autonomy and control strength are proportionate to business impact and risk tolerance. |
| Cost-effective | Existing controls are reused where they provide adequate assurance. |
| Usable | Controls do not make the agent impractical for its intended users and business process. |
| Measured | Leadership receives evidence that the controls are operating effectively. |
The objective is not to maximize every attribute. It is to select and measure the attributes that are fit-for-purpose for the relevant business process.
An internal research assistant and an agent authorized to modify production infrastructure should not receive the same risk treatment.
A practical control approach
NIST CSF 2.0 organizes cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond, and Recover. That structure provides a clear executive view of the AI-agent lifecycle. NIST Cybersecurity Framework 2.0
| NIST CSF function | Priority action | Relevant SCF domains | Example measure |
|---|---|---|---|
| Govern | Establish ownership, acceptable uses, risk tiers, and approval authority. | Governance, Risk Management, Artificial Intelligence & Autonomous Technologies | Percentage of agents with business and technical owners |
| Identify | Inventory agents, models, data, integrations, identities, and dependencies. | Asset Management, Data Classification & Handling | Percentage of production agents in the approved inventory |
| Protect | Apply independent identities, least privilege, data restrictions, and action limits. | Identification & Authentication, Data Classification & Handling, Configuration Management | Percentage of agents using dedicated least-privileged identities |
| Detect | Log tool calls, access, actions, policy violations, and abnormal behavior. | Continuous Monitoring, Artificial Intelligence & Autonomous Technologies | Percentage of consequential actions captured in centralized logs |
| Respond | Provide suspension, credential revocation, investigation, escalation, and stakeholder communications. | Incident Response, Security Operations | Measured time to suspend an agent and revoke access |
| Recover | Restore affected systems, reverse supported actions, and improve controls based on lessons learned. | Business Continuity, Disaster Recovery, Change Management | Percentage of high-impact agents included in recovery exercises |
The SCF’s Artificial Intelligence & Autonomous Technologies domain addresses AI risk classification, automated decision-making governance, incident response, data quality, and third-party AI governance. Its Identification and Authentication domain also applies least privilege to non-person entities such as service accounts, APIs, and automated processes. SCF AI and Autonomous Technologies, SCF Identification and Authentication
These domains can be integrated with controls already supporting conventional applications and automation. A separate control stack should be introduced only when existing capabilities cannot provide the required assurance.
Prioritized decisions for leaders
1. Determine where autonomy is appropriate
Begin with agents that recommend actions. Increase autonomy only after the organization has demonstrated reliable controls, monitoring, and recovery.
Actions involving financial transactions, regulated data, production systems, external communications, or safety-sensitive processes should require stronger authorization.
2. Assign risk ownership to the business
Cybersecurity should advise on threats, architecture, and control effectiveness. The business owner should decide whether the remaining risk is acceptable in relation to the expected benefit.
Legal, privacy, compliance, finance, procurement, IT, and resilience teams should participate when their responsibilities are affected.
3. Separate agent identity from employee identity
Each production agent should use an independent identity with only the permissions required for its approved function. It should not inherit all permissions belonging to the employee who created or operates it.
The SCF treats identity as the control plane for access and explicitly applies least privilege to automated and other non-person entities. SCF Identification and Authentication
4. Place controls around actions, not only responses
Content filtering may reduce undesirable model output, but action-level controls limit what that output can cause.
Examples include:
- Transaction or spending limits
- Approved recipients and destinations
- Restricted data types
- Rate limits
- Time-limited credentials
- Human approval for material actions
- Sandboxed code execution
- Reversible transactions
- Automatic suspension thresholds
5. Define continuous assurance
Security testing should address prompt injection, malicious retrieved content, sensitive-data exposure, excessive permissions, misuse of connected tools, and failure across multistep workflows.
Testing should be repeated after material changes and at a frequency justified by the agent’s business impact.
Questions leaders should ask
- Which AI agents can currently act in our environment?
- Does each agent have an accountable business owner?
- What information, applications, and infrastructure can each agent access?
- Does every agent use an independent, least-privileged identity?
- Which actions require human approval?
- Are consequential actions fully logged and attributable?
- How do we detect an agent acting outside its intended purpose?
- How quickly can access be revoked?
- Can important changes be reversed?
- What model, permission, or tool changes require reassessment?
- When was each high-impact agent last tested?
- Which legal, contractual, privacy, or regulatory requirements apply to the specific use case?
Regulatory applicability will depend on geography, industry, data, and the nature of automated decisions. Legal and compliance teams should validate those obligations rather than relying on a general AI security framework as evidence of compliance.
Shawn’s perspective
Organizations should avoid two unproductive extremes: allowing AI agents to expand without sufficient governance or applying so many controls that valuable uses become impractical.
A better approach is progressive autonomy.
Start with a clearly defined business problem. Give the agent the minimum information and authority needed to address it. Measure its performance. Validate its controls. Expand its capabilities only when the additional business value justifies the additional risk.
This approach is fit-for-use because it supports adoption instead of blocking it. It is fit-for-purpose because the control model follows the business process. It is risk-justified because stronger controls are applied to more consequential actions. It is cost-justified because existing security capabilities are reused before new technologies are purchased.
The goal is not unlimited autonomy. The goal is autonomy that is governed, authorized, monitored, and recoverable.
Conclusion and next actions
Organizations do not need to solve every aspect of AI-agent security before taking responsible action.
Over the next 30 days, leaders can ask their teams to:
- Identify all production and pilot agents.
- Assign business and technical owners.
- Document connected data, tools, and permissions.
- Separate agent identities from human accounts.
- Select the actions that require human approval.
- Verify logging and emergency revocation.
- Prioritize deeper testing for agents with the greatest potential business impact.
These foundational measures provide immediate risk reduction while creating the information needed for a longer-term AI security architecture.
Leave a Reply