AI Attack Surface for Defenders

In this room, the AI attack surface means the places where an attacker can introduce influence into an AI system, extract value from it, or abuse connected functionality around it. For defenders, that includes more than the model. It includes the application layer, retrieval pipeline, connected tools, data stores, output handling, APIs, logs, and identity boundaries around the system.

Official guidance treats AI risk as a system-level problem. The model may be the reasoning core, but the attack surface often expands at the boundaries where data enters, tools are called, outputs are rendered, or sensitive information is retained.

A useful defender mindset is: do not ask only what the model can say.

Ask what the overall system can be made to do, reveal, or trust. Then ask what can be changed today to make that abuse path harder: remove a connector, narrow a scope, split a trust lane, or add a gate before action.

Attack surface mapping starts by identifying where influence enters the system and where the results of that influence are exposed. In AI applications, user prompts are only one entry point. Untrusted files, retrieved documents, websites, emails, API requests, plugins, and memory can also shape model behavior or feed sensitive data into context.

Exposure points matter too. Outputs shown to end users, tool actions, emails, tickets, database updates, logs, and analytics pipelines can all become places where the effects of bad model behavior spread.

A good surface map includes both ingress and egress: where input gains influence, and where model behavior gains consequence.

Once defenders know where the surface exists, they need to identify the boundaries that matter most. A trust boundary exists where untrusted content crosses into something more privileged: trusted context, internal data, tool execution, or user-visible output.

High-value assets in AI systems often include sensitive enterprise data, model access, system prompts, secrets, internal files, tool credentials, and the permissions attached to integrated services.

The important question is not only "what can the model read?" It is also "what can it cause to happen?" A read-only assistant and an agent with business actions do not have the same attack surface.

Defenders reduce attack surface by removing unnecessary exposure, narrowing permissions, and placing controls at the exact boundary where risk appears. That usually means fewer integrations, stricter tool scopes, clearer separation between trusted instructions and untrusted content, safer output handling, and stronger monitoring around model use.

A smaller surface is easier to defend. If a feature does not need live browsing, mailbox access, file writes, or privileged business actions, those capabilities should not be exposed to the model.

Good hardening is not about making the system look secure. It is about reducing what an attacker can actually reach.

Inspect the support-assistant system map below and prioritize the nodes a defender should review first. The goal is to spot where untrusted influence enters and where consequence becomes real.

Select every asset that would materially matter if this assistant were misused.

Choose the capability a defender should usually remove or narrow first if the assistant only needs read-only support help.