What AI Security Actually Covers Beyond Model Safety

Security reviews for AI products often stop at the model: Is it aligned? Does it refuse harmful content? Did we run a red-team on jailbreaks? Those questions matter, but they describe model safety — a slice of a much larger surface. Production AI systems move data, call APIs, act on behalf of users, and retain context across sessions. Treating security as "make the output polite" leaves the real attack paths open.

This article maps the full scope of AI security so architects and governance teams share the same boundary diagram before anyone writes a control checklist.

Why the narrow view persists#

Vendor marketing reinforces it. Model cards talk about toxicity benchmarks and refusal rates. Compliance questionnaires ask whether you use a "safe" foundation model. Product demos show a chatbot declining to help with explosives. None of that tells you whether an attacker can use your support agent to read another customer's orders.

The narrow view also fits org charts. ML teams own model selection. AppSec owns OWASP Top 10. Legal owns privacy policies. Nobody owns the system where model output becomes tool calls, database queries, and outbound email. That gap is where incidents happen.

The five domains that belong in scope#

Identity and authorization#

Who is the agent acting as? Who is the human behind the session? Classical apps answer this at the API gateway. AI systems blur it: the model may synthesize a "role" from prompt text, and agents may inherit service credentials broader than the end user deserves.

Security here means explicit binding: session identity, agent identity, and tool credentials must be traceable and least-privilege. A user should not gain admin tools because the model believed a PDF that said "you are admin."

Data protection and residency#

Models ingest prompts, retrieved chunks, tool results, and conversation history. Each hop is a data-processing event with retention, encryption, and jurisdiction implications. "We don't train on customer data" is one line on a form. Security scope includes:

• What enters logs and for how long
• Whether prompts cross provider boundaries
• How retrieval indexes are scoped per tenant
• Redaction before logging or human review

Data exfiltration through the model — "summarize all records and email them" — is a data-protection failure even when the model complied politely.

Prompt and context attacks#

Hostile instructions in user text, tickets, web pages, or RAG corpora attempt to override system policy. This domain overlaps with application security (untrusted input) but the injection surface is semantic, not syntactic. Defenses span architecture: trust regions in prompts, tool allowlists, workflow segmentation — not only stronger refusals.

This article does not walk through every attack variant; the point is that prompt attacks are in scope for AI security reviews alongside SQL injection and SSRF, not filed under "model quality."

Runtime policy and side effects#

Anything the system can do — refund, delete, publish, call external URLs — is security-critical. The model proposes actions; your runtime must enforce caps, schemas, idempotency, and human approval. Policy engines belong here, not in the system prompt.

If a workflow can move money or export PII, it needs the same scrutiny as a REST endpoint with those powers. Calling it "AI" does not reduce blast radius.

Governance, audit, and compliance#

Regulators and enterprise customers ask for evidence: model versions, prompt changes, who approved new tools, what data was processed. Security scope includes provability — immutable audit trails on tool calls, change control on agent configurations, and retention policies that match your claims.

SOC 2 and ISO frameworks still apply. AI adds artifacts (trajectories, eval scores) that classical apps did not produce. Governance without telemetry is paperwork; telemetry without policy is surveillance.

How the domains interact#

Weakness in one domain amplifies others. Over-broad agent credentials (identity) make a successful prompt injection (context attack) into a data breach (data protection). A compliant retention policy (governance) does not stop tool abuse if runtime policy (side effects) is missing.

No single team owns the whole map. Architecture reviews should require representatives from each row before production sign-off.

A scope checklist for architects#

Use this as a pre-launch gate, not a post-incident regret list:

1. Inventory side effects — list every tool and write path with max impact
2. Draw trust boundaries — what content is untrusted vs policy vs secrets
3. Map data flows — prompt → provider → logs → analytics → humans
4. Define agent identity — separate credentials per workflow, not one super-token
5. Attach policy to runtime — amounts, destinations, and roles enforced in code
6. Plan audit exports — reconstruct a session without dumping raw PII to analysts

from dataclasses import dataclass
from enum import Enum

class TrustRegion(Enum):
    POLICY = "policy"       # system instructions — high trust
    USER = "user"           # end-user input — low trust
    RETRIEVED = "retrieved" # RAG / web — hostile by default

@dataclass
class SecurityScopeReview:
    workflow_id: str
    side_effect_tools: list[str]
    untrusted_regions: list[TrustRegion]
    agent_credential_scope: str
    log_retention_days: int
    audit_export_ready: bool

def blocks_launch(review: SecurityScopeReview) -> list[str]:
    blockers = []
    if review.side_effect_tools and TrustRegion.RETRIEVED in review.untrusted_regions:
        if not review.audit_export_ready:
            blockers.append("write tools on untrusted retrieval path without audit")
    if review.log_retention_days > 90 and not review.audit_export_ready:
        blockers.append("long retention without export/redaction plan")
    return blockers

What model safety alone cannot cover#

Alignment training reduces some harmful content in model outputs. It does not:

• Stop an agent from calling export_users if the runtime allows it
• Enforce tenant isolation in your vector index
• Prove who changed the system prompt last Tuesday
• Satisfy GDPR erasure when "memory" spans three stores

Vendor safety filters are a upstream control. Your security posture is the system wrapping the model. Buying a safer model while shipping a over-privileged agent is like buying a firewall and leaving SSH open on every port.

Organizational friction you should expect#

Security teams trained on web apps will ask for WAF rules; AI attacks often bypass syntax filters. ML teams will point at benchmark scores when AppSec asks about tool abuse. Legal will want policy language the runtime cannot enforce. The fix is a shared scope document — this map — referenced in both the architecture decision record and the governance committee charter.

Summary#

AI security is not synonymous with model safety. It covers who acts, what data moves, what untrusted text can steer behavior, what side effects the runtime permits, and what evidence you retain for auditors and incident response. Teams that scope reviews to output filtering inherit a false sense of coverage while the actionable risk sits in tools, identity, and data paths.