AI is Expanding the Attack Surface

Artificial intelligence is moving rapidly from experimentation into production. Organizations are embedding AI into customer-facing applications, internal workflows, software development, analytics, and decision-making systems.

That creates opportunity. It also creates a new class of cybersecurity problems.

The security challenge is not simply whether an AI model can be compromised. It is whether the systems, data, identities, integrations, and workflows surrounding that model can be trusted.

A New Attack Surface

Traditional application security focuses heavily on software, infrastructure, networks, and identities. AI systems introduce additional components that need to be evaluated.

Models can process sensitive information. Applications can give models access to internal systems. Agents can take actions on behalf of users. Third-party AI services can introduce dependencies outside an organization’s direct control.

This expands the attack surface in several directions:

• Prompt injection — manipulating model inputs to influence behavior or bypass intended safeguards.
• Data exposure — sensitive information being submitted to models, retained in logs, or exposed through poorly designed integrations.
• Excessive agency — AI systems receiving more permissions or access than their function actually requires.
• Model and supply-chain risk — dependencies on third-party models, datasets, plugins, APIs, and infrastructure.
• Insecure integrations — AI connected to internal systems without sufficient authentication, authorization, or monitoring.
• Shadow AI — employees adopting AI tools without security, privacy, or governance teams knowing what data is being processed.

The common thread is familiar: excessive trust combined with insufficient control.

The Model Is Only Part of the Problem

An AI model does not exist in isolation.

Consider an internal AI assistant with access to company documentation. The model may be well secured, but if the underlying retrieval system does not enforce document-level permissions, the assistant can become an unintended path around existing access controls.

The same principle applies to AI agents.

An agent that can read email, access customer records, execute code, or modify production systems has meaningful authority. Treating that agent as simply another software feature misses the security implications of what it can actually do.

AI security therefore has to extend beyond the model itself.

Organizations should evaluate the complete system: model, application, data, identity, permissions, integrations, infrastructure, and human workflow.

Security by Design

The most effective approach is to incorporate security requirements before an AI system reaches production.

That starts with understanding what the system can access and what it is capable of doing.

Questions worth asking include:

• What data can the system access?
• Which users can interact with it?
• What actions can it perform?
• Which external services can it call?
• What happens when the model behaves unexpectedly?
• Can its actions be audited?
• Can access be revoked quickly?
• What sensitive information could appear in prompts, outputs, logs, or training data?

The answers should inform architecture and control design.

Least privilege remains relevant. Strong identity controls remain relevant. Network segmentation remains relevant. Logging, monitoring, testing, and incident response remain relevant.

AI does not replace these principles. It makes applying them more important.

Testing AI Systems Like Real Systems

AI security cannot rely entirely on configuration reviews or vendor assurances.

Systems should be tested against realistic abuse cases.

That can include prompt injection testing, authorization testing, sensitive-data exposure scenarios, adversarial input testing, unsafe tool-use scenarios, and attempts to move from model interaction into higher-value systems.

The objective is not to prove that an AI system can never be manipulated. No serious security program can make that promise.

The objective is to understand what happens when it is manipulated.

If an attacker succeeds in influencing a model, what can they access? What can they cause it to do? What controls stop the attack from becoming a material security event?

Those are much more useful questions than whether the model itself appears secure.

The Governance Problem

Technical controls are only part of the equation.

Organizations also need clear ownership of AI security. Someone should know which AI systems exist, what information they process, what permissions they have, which vendors support them, and who is responsible when something goes wrong.

A practical AI security program should address:

• AI asset inventory
• Data classification and handling
• Vendor and third-party risk
• Identity and access controls
• Model and application testing
• Logging and monitoring
• Secure development practices
• Incident response procedures
• Employee usage policies
• Ongoing security review

The goal is not to prevent employees from using AI.

The goal is to make its use visible, governed, and defensible.

AI Security Is Cybersecurity

The temptation is to treat AI security as an entirely new discipline requiring an entirely new security philosophy.

It does not.

AI introduces unfamiliar technologies and attack paths, but many of the underlying security problems are recognizable: excessive permissions, exposed data, weak authentication, insecure integrations, poor visibility, vulnerable dependencies, and inadequate incident preparation.

The organizations that handle AI security well will not necessarily be the ones with the most sophisticated models.

They will be the ones that understand what those models can access, what they can do, how they can fail, and how quickly the organization can detect and contain the consequences.

AI is becoming part of the infrastructure.

It should be secured accordingly.