When an AI agent can retrieve sensitive records, execute commands, or change a business system, someone has granted it authority. Can your organization identify that person, explain the limits of the approval, and produce evidence that those limits hold?
That is the question I would put before a leadership team this week.
The threat has moved into operations
On October 21, CrowdStrike reported four previously unreported threat actors using AI agents to make decisions and execute commands during campaigns observed between May and August 2026. One operator compromised at least 15 healthcare entities in Argentina; credentials and medical records were taken from at least one victim. Another operator targeted organizations across several industries, including healthcare and biotech in the United States and Brazil. [1]
Those findings describe adversaries using AI against organizations. They do not establish that the victims' own AI systems caused the compromises. That distinction matters. My conclusion is that leaders must address both the changing external threat and the authority they grant AI inside their organizations.
The consequences depend on the workflow. Unauthorized access may expose patient records, employee information, customer data, or intellectual property. An agent with write access may change financial records or disrupt operations. The relevant question is what it can reach and do, and how quickly people can contain a failure.
Start with the authority already granted
An approved application may acquire new AI features after purchase. A departmental pilot may connect to production data. A browser extension or vendor automation may operate outside the AI inventory. Discovery must extend beyond tools marketed as AI.
For each use, record the business owner, purpose, data categories, connected systems, machine identity, permitted actions, and approval conditions. Security, privacy, compliance, procurement, and operational leaders should review the same workflow, with responsibilities matched to the exposure. A vendor's assurance statement cannot substitute for the organization's own decision.
Put AI questions into the VSRA
A Vendor Security Risk Assessment should examine the actual service and its configuration. These questions give the discussion a practical starting point:
Data use: Are prompts, uploaded files, retrieved records, outputs, or logs used for training or service improvement? Which contractual terms and settings govern that use?
Data custody: Which models, subprocessors, support teams, and locations receive the information? What are the retention periods, backup exceptions, and available deletion evidence?
Agent authority: Which tools, APIs, and other agents can the service invoke? What prevents it from expanding its permissions, using unrelated credentials, or sending information to an unapproved destination?
Independent controls: Which consequential actions require human approval? Show how downstream authorization blocks an unauthorized action even when the model requests it.
Assurance and change: Provide relevant security test results and remediation evidence. How are model, subprocessor, tool, and autonomy changes disclosed and reassessed?
Response and records: Can we obtain activity logs, revoke credentials, stop active jobs, and preserve evidence? Who must notify us of an incident, and under what contractual timeframe?
Require evidence appropriate to the risk: contract language, data-flow documentation, permission settings, test results, and a demonstration. Unanswered questions should become approval conditions or documented risks, with an owner and a deadline.
Ask the vendor. Verify the evidence. Assign accountability.
Turn approval into enforceable requirements
A policy establishes organizational expectations. A standard makes those expectations specific enough to implement and test. The following are illustrative requirements for adaptation to an organization's risk and obligations, rather than quotations from a regulation or published standard.
Sample AI acceptable use policy
Employees and third parties must use approved AI services only for documented purposes and authorized data categories. Sensitive information must not enter an unapproved AI service. Connecting an AI service to enterprise systems, or enabling autonomous actions, requires documented review and approval before activation. Exceptions require a named risk owner, compensating controls, and an expiration date.
Sample AI agent security standard
Each production agent must use an identifiable, managed identity with the minimum required permissions. Authorized tools, destinations, and actions must be explicitly restricted. Production changes, destructive actions, and external disclosures designated as high impact must require approval enforced outside the model. Credentials must be revocable, and the ability to stop execution must be tested before release.
Sample audit evidence standard
Record the initiating identity, agent and model version, tool requests, authorization decisions, and action outcomes. Protect audit records from alteration by the agent and preserve them under the approved retention schedule. Minimize sensitive prompt content and restrict access to logs; evidence collection must not create another uncontrolled repository.
Test the boundary and the recovery
OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency. Its guidance includes limiting tools and permissions and requiring approval for high-impact actions. [2] A written instruction to an agent is insufficient evidence of an enforced boundary.
Threat modeling should follow the complete path from input to action. Consider a malicious instruction hidden in a document, a compromised credential, an unauthorized request from another agent, or a failed isolation boundary. Ask which independent control would stop the next step and what the organization would lose if it did not.
Then demonstrate that control in a safe test environment. Verify that the agent cannot reach excluded records or invoke prohibited tools, that high-impact actions stop for approval, and that revocation prevents further access. Test stopping active execution, preserving independent logs, and restoring affected services. Document failures and retest after remediation or material change.
Make the approval defensible
The NIST AI Risk Management Framework provides voluntary guidance for managing AI risks; its Generative AI Profile adds actions addressing generative AI concerns. [3] Organizations still need to translate that guidance into decisions for their own systems.
At Your Next Leadership Meeting
Ask: "For one AI service operating today, can we show who approved its access, which actions it can take, and evidence that it cannot exceed those limits?" A credible answer should include a named owner, documented permissions, vendor assurance evidence, and a tested means of stopping execution.
The Takeaway
Approving an AI service means accepting responsibility for the authority it receives. Leaders need evidence that its operating limits are enforced—and that intervention works when those limits fail.
Continue the Exploration
This topic connects to AI Security Governance for the Enterprise™, Threat Modeling Healthcare AI™, and Future of Threat Modeling™ in The vCSO Series™, extending the discussion into vendor assessment, enforceable requirements, and threats across connected systems.
#AIGovernance#ExecutiveLeadership#Cybersecurity#Privacy#Compliance#ThreatModeling#HealthcareCybersecurity#HIPAA#CybersecurityLeadership#RiskManagement#HealthcareIT
Sources
- CrowdStrike — CrowdStrike Uncovers New Agentic AI Campaigns, October 21, 2026
- OWASP — LLM06 2025 Excessive Agency
- NIST — AI Risk Management Framework and Generative AI Profile
Ken Williams | Leadership Brief | Issue 002 • October 2026