The AI attack surface is already operational

The 2026 Verizon DBIR reports generative AI bolstering 15% of attack techniques in its dataset. NIST's Generative AI Profile frames risk across the AI lifecycle, while NIST's preliminary Cyber AI Profile is being organized around three areas: securing AI system components, conducting AI-enabled cyber defense, and defending against AI-enabled attacks.

The NIST Cyber AI Profile is preliminary as of this article's date. It is useful direction, not a final control standard. The immediate lesson is stable: organizations need to treat AI as both a system to secure and a capability changing how defenders and attackers work.

AI changes both sides of the system

On the attacker side, AI can accelerate research, content variation, translation, code modification, data triage, and interaction. It can make familiar techniques cheaper and faster without inventing a new vulnerability class.

On the defender side, AI can summarize alerts, correlate records, draft queries, explain code, propose response steps, and help teams search large evidence sets. Those benefits also introduce new trust decisions: which data may enter the model, which output can drive an action, and who verifies the result?

The relevant security boundary is not the chat window. It is every identity, dataset, connector, tool, and approval path behind it.

An AI inventory needs seven parts

1. Use case and owner. What decision or workflow uses AI, who is accountable for it, and what happens if it is wrong?
2. Model and provider. Which model, version, hosting mode, region, service terms, and retention configuration apply?
3. Data flow. What enters prompts, retrieval stores, fine-tuning, logs, evaluations, and output destinations?
4. Identity and authorization. Which user, service account, token, role, and tenant can invoke the system or its tools?
5. Tools and agents. What can the system read, write, execute, purchase, publish, delete, or send? Where is approval required?
6. Software supply chain. Which client libraries, orchestration frameworks, plugins, models, containers, and deployment services are involved?
7. Evaluation and incident path. How are unsafe output, data leakage, prompt injection, model drift, and unauthorized action detected, contained, and investigated?

A control model for AI-enabled workflows

Separate read, propose, and act

A system that can retrieve information does not need the same authority as a system that can change a firewall, send a message, or issue a refund. Use separate identities and explicit gates for side effects.

Assume retrieved content is untrusted

Documents, web pages, tickets, emails, source repositories, and tool output can contain instructions designed to redirect an AI agent. Treat content as data, constrain tool arguments, and verify authorization outside the model.

Bound tools by destination and effect

Allowlisted origins, schema-validated inputs, length limits, per-destination pacing, transaction ceilings, and non-interactive confirmation rules are more reliable than asking a model to "be careful."

Keep evidence around the decision

Record model and prompt version, retrieved sources, tool requests, approval, output, and resulting state without logging secrets. An answer that cannot be reconstructed is difficult to audit or improve.

Design a stop path

Operators need a way to revoke credentials, halt jobs, isolate connectors, reject queued actions, and identify what the system already changed.

What to measure first

• Percentage of AI use cases with an owner, data classification, and approved model/provider.
• Percentage of tool-enabled workflows split between read-only and state-changing identities.
• Number of connectors able to reach secrets, customer data, production changes, payments, or external communications.
• Coverage of prompt-injection and data-exfiltration tests for high-impact workflows.
• Rate of AI-proposed actions independently reviewed before execution.
• Time required to revoke an agent's credentials and reconstruct its recent actions.

How Argus fits

Argus's provider-neutral command layer, capability manifests, source provenance, request-safety controls, outbound write gates, and release checks are useful foundations for agent integration. The security objective is to give an agent the smallest relevant Argus capability instead of ambient access to the whole toolkit.

The platform does not label model output as evidence merely because it is confident. Evidence comes from bound artifacts, source records, verified responses, and controlled observations. That distinction becomes more important as AI makes plausible text inexpensive.