Managing Cybersecurity Risks While Adopting AI Technologies
The 2025 update to the OWASP Top 10 for LLM Applications added a category called "Excessive Agency" — a direct response to AI systems that now act on their own. Here's what actually changed, and the real frameworks worth knowing before you deploy AI anywhere near sensitive data.
The GetCoreTech Team Aug 27, 2026 · 7 min read · Updated Sep 12, 2026
Managing Cybersecurity Risks While Adopting AI Technologies
The framework organizations actually use to catalogue AI security risks — OWASP's Top 10 for LLM Applications — was updated in 2025 to add a category called "Excessive Agency," created specifically because AI systems are no longer just answering questions; they're taking actions, calling tools, and making decisions with real consequences. If you're evaluating AI risk in 2026, that shift is the single most important thing to understand: the risks aren't just about a model giving a wrong answer anymore, they're about what an AI system with too much autonomy is allowed to actually do.
The Real Frameworks Worth Knowing
Three references are worth knowing by name, because they're what security teams and auditors actually check against, rather than vendor marketing. OWASP Top 10 for LLM Applications was updated in 2025 to add Unbounded Consumption (resource exhaustion and runaway cost risk), Vector and Embedding Weaknesses (covering RAG systems specifically), System Prompt Leakage, and Excessive Agency. MITRE ATLAS is the AI-specific counterpart to the well-known MITRE ATT&CK framework, cataloguing real-world adversarial machine learning tactics and techniques observed against AI systems in production. ISO/IEC 42001 is the first international management-system standard specifically for AI, covering governance, risk assessment, and accountability across an organization's AI systems, similar in structure to how ISO 27001 works for general information security.
None of these are products to buy — they're the shared vocabulary and checklists that security teams, auditors, and regulators increasingly reference. Citing them by name, instead of a list of vendor product names, is also simply more useful to a reader trying to actually assess their own risk.
Excessive Agency: The Risk Category That Didn't Exist a Few Years Ago
As AI systems move from "generate text" to "take actions" — booking things, executing code, calling other tools and APIs, modifying records — a new class of risk emerges that has nothing to do with data poisoning or adversarial inputs. It's simply: what happens when an AI agent is granted more permission than it needs, and something (a bad instruction, a manipulated input, a bug) causes it to use that permission destructively? OWASP's 2025 update added Excessive Agency as its own named category precisely because this had become common enough to need a dedicated response, separate from older LLM-specific risks.
Practically, this means the traditional advice to "limit access" now needs to extend specifically to what actions an AI agent is authorized to take autonomously, not just what data it can read. An agent that can read a database is a data-exposure risk; the same agent granted permission to also write, delete, or execute transactions is a fundamentally different and larger risk.
Data Poisoning, Adversarial Inputs, and Model Theft — Still Real, Still Relevant
The older, more established risk categories haven't gone away, they've just been joined by newer ones. Data poisoning — inserting manipulated data into a training set to bias or degrade a model's outputs — remains a documented risk, particularly for any system trained or fine-tuned on user-submitted or scraped data. Adversarial inputs, where small, deliberately crafted changes to an input cause a model to misclassify or misbehave, remain relevant especially for computer-vision and content-moderation systems. Model inversion and extraction attacks, where an attacker reconstructs training data or model behavior from repeated queries, remain a genuine concern anywhere models are trained on sensitive data like health or financial records.
Practical Steps, Mapped to Actual Categories
Rather than a generic checklist, here's how practical controls map onto the frameworks above. Validate and monitor training and fine-tuning data sources to address data poisoning risk directly. Explicitly scope what actions an AI agent can take autonomously versus what requires human approval — this is the direct mitigation for Excessive Agency. Apply rate limiting and cost monitoring on AI endpoints to address Unbounded Consumption, which is both a security and a budget risk. Enforce access controls and encryption on models and embeddings in storage and transit to address model theft and Vector/Embedding Weaknesses. Run continuous output monitoring for anomalies as a practical defense against adversarial inputs and unexpected model drift. And maintain a documented AI governance policy — the core requirement underlying ISO/IEC 42001, and increasingly something auditors and enterprise customers ask to see directly.
Where This Intersects With Regulation
Organizations handling sensitive data through AI systems still need to account for existing regulations — GDPR for EU residents' data, HIPAA for health data in the US, CCPA for California residents — regardless of whether the processing involves AI. AI-specific regulation is also maturing: the EU AI Act's phased obligations continue rolling out, and a growing number of enterprise customers and auditors now ask specifically whether a vendor's AI governance aligns with ISO/IEC 42001, making it worth tracking even for organizations not currently required to comply with it.
The Honest Bottom Line
AI adoption doesn't require choosing between moving fast and staying secure, but it does require treating AI-specific risks as their own category rather than assuming general software security practices automatically cover them. The clearest sign an organization is behind: if "how much autonomy does this AI agent actually have" isn't a question already being asked before deployment, that's the gap most worth closing first in 2026.
FAQ
What is "Excessive Agency" in AI security, and why is it new?
Excessive Agency is a risk category OWASP added to its Top 10 for LLM Applications in its 2025 update. It describes the risk of an AI agent being granted more autonomous permission — to take actions, call tools, or modify data — than it actually needs, so that a bad instruction or manipulated input can cause real damage. It's new because agentic AI systems that take autonomous action have become far more common.
What is MITRE ATLAS?
MITRE ATLAS is the AI-specific counterpart to the well-known MITRE ATT&CK framework. It catalogues real-world adversarial machine learning tactics and techniques that have actually been observed against AI systems in production, giving security teams a shared reference for threat modeling AI-specific attacks.
What is ISO/IEC 42001?
ISO/IEC 42001 is the first international management-system standard specifically for AI, covering governance, risk assessment, and accountability across an organization's AI systems. It's structured similarly to how ISO 27001 works for general information security, and is increasingly referenced by enterprise customers and auditors evaluating AI vendors.
Is data poisoning still a real risk in 2026?
Yes. Any AI system trained or fine-tuned on user-submitted or scraped data remains vulnerable to data poisoning, where manipulated data is inserted into a training set to bias or degrade the model's outputs. This risk hasn't gone away — it's simply now one of several categories organizations need to track, alongside newer risks like Excessive Agency.
How is Excessive Agency different from a traditional data-access risk?
A traditional access-control risk is about what data a system can read. Excessive Agency is about what actions a system can autonomously take — writing, deleting, executing transactions, calling other tools. An AI agent with read-only database access is a data-exposure risk; the same agent with write or execute permission is a categorically larger risk.
Do small and medium businesses need to worry about frameworks like MITRE ATLAS?
Not usually in a formal compliance sense, but the underlying principles apply regardless of size: know what data your AI systems touch, limit what autonomous actions any AI agent can take without human approval, and monitor for unusual outputs. Cloud-based AI platforms with built-in security controls make these steps accessible without a dedicated security team.
What regulations apply to AI systems handling sensitive data?
The AI itself doesn't create a separate regulatory category for most existing laws — GDPR (EU), HIPAA (US health data), and CCPA (California) still apply based on the type of data being processed, regardless of whether AI is involved. Separately, AI-specific regulation like the EU AI Act is rolling out its obligations in phases.
What's the single most overlooked risk when adopting AI right now?
Whether an AI agent has been granted more autonomous permission than it actually needs to do its job. This is the practical form of Excessive Agency, and it's often overlooked because it doesn't require any change to the AI model itself — it's a permissions and scoping decision that's easy to skip during fast deployment.
FAQ
Excessive Agency is a risk category OWASP added to its Top 10 for LLM Applications in its 2025 update. It describes the risk of an AI agent being granted more autonomous permission — to take actions, call tools, or modify data — than it actually needs, so that a bad instruction or manipulated input can cause real damage. It's new because agentic AI systems that take autonomous action have become far more common.
MITRE ATLAS is the AI-specific counterpart to the well-known MITRE ATT&CK framework. It catalogues real-world adversarial machine learning tactics and techniques that have actually been observed against AI systems in production, giving security teams a shared reference for threat modeling AI-specific attacks.
ISO/IEC 42001 is the first international management-system standard specifically for AI, covering governance, risk assessment, and accountability across an organization's AI systems. It's structured similarly to how ISO 27001 works for general information security, and is increasingly referenced by enterprise customers and auditors evaluating AI vendors.
Yes. Any AI system trained or fine-tuned on user-submitted or scraped data remains vulnerable to data poisoning, where manipulated data is inserted into a training set to bias or degrade the model's outputs. This risk hasn't gone away — it's simply now one of several categories organizations need to track, alongside newer risks like Excessive Agency.
A traditional access-control risk is about what data a system can read. Excessive Agency is about what actions a system can autonomously take — writing, deleting, executing transactions, calling other tools. An AI agent with read-only database access is a data-exposure risk; the same agent with write or execute permission is a categorically larger risk.
Not usually in a formal compliance sense, but the underlying principles apply regardless of size: know what data your AI systems touch, limit what autonomous actions any AI agent can take without human approval, and monitor for unusual outputs. Cloud-based AI platforms with built-in security controls make these steps accessible without a dedicated security team.
The AI itself doesn't create a separate regulatory category for most existing laws — GDPR (EU), HIPAA (US health data), and CCPA (California) still apply based on the type of data being processed, regardless of whether AI is involved. Separately, AI-specific regulation like the EU AI Act is rolling out its obligations in phases.
Whether an AI agent has been granted more autonomous permission than it actually needs to do its job. This is the practical form of Excessive Agency, and it's often overlooked because it doesn't require any change to the AI model itself — it's a permissions and scoping decision that's easy to skip during fast deployment.
The GetCoreTech Team
We write about the SaaS, AI, and infrastructure decisions builders actually have to make.
Comments
Log in or sign up to join the discussion.
Loading comments…