AI Security Architecture

Review scope and evidence labels

This page defines AI Security Architecture as a methodology for designing and reviewing AI-enabled systems. It focuses on controls, trust boundaries, threat modeling, identity, data protection, application security, monitoring and audit evidence.

Evidence labels used on this page:

Official guidance — based on public official guidance such as NIST or CISA material.
Community security guidance — based on public security community material such as OWASP or MITRE ATLAS.
Author analysis — interpretation for AI security, governance, architecture and operational risk on this site.
Implementation evidence required — records that must exist before a control can be treated as operating.

This page is not a certification claim and does not imply offensive AI red-team certification. It is a public knowledge profile used to connect AI governance, AI risk, secure engineering and security architecture discussions on this site.

Methodology snapshot

Field	Value
Category	AI security and security architecture
Research type	Methodology
Core question	How should an organisation design and prove security around AI-enabled systems?
Main scope	LLM applications, RAG workflows, AI agents, AI-assisted development, model-enabled services and vendor AI integrations
Key concerns	Prompt injection, data leakage, excessive privilege, insecure tool use, weak review gates, supply-chain risk, missing audit evidence
Reference families	NIST AI RMF, OWASP LLM Top 10, MITRE ATLAS, NIST SSDF, Zero Trust guidance
Review status	Public guidance reviewed; local implementation requires environment-specific assessment

What AI Security Architecture means

AI Security Architecture is the discipline of designing AI systems so that security is part of the architecture, not a late checklist. Evidence: Official guidance; Community security guidance; Author analysis.

It connects business purpose, data flows, identity, model behavior, application code, tool access, logging, monitoring, review gates and accountability into one control model. Evidence: Author analysis.

For this site, the term is used for the architecture layer between broad AI Governance and concrete implementation work such as secure AI-assisted development, RAG security, LLM application security and audit evidence. Evidence: Author analysis.

What it is not

AI Security Architecture is not:

only an AI ethics statement,
only model testing,
only a cloud-security checklist,
only prompt filtering,
a guarantee that an AI system is safe,
a replacement for secure software development,
a replacement for governance, risk management or human accountability,
evidence of offensive red-team certification by itself.

A credible architecture must be supported by records: design decisions, risk assessments, threat models, access reviews, test results, monitoring evidence and accepted residual risks. Evidence: Author analysis; Implementation evidence required.

Architecture view

A practical AI security architecture should make the main trust boundaries visible.

Users / business process
        ↓
Application or workflow layer
        ↓
Prompt, policy and orchestration layer
        ↓
Model / LLM / AI service
        ↓
Tools, APIs, plugins and actions
        ↓
Data sources, RAG index, logs and evidence store

Each boundary can fail differently. User input may carry prompt injection. Application logic may expose excessive context. The model may produce unsafe output. Tools may execute actions with too much privilege. RAG sources may leak data or become poisoned. Logs may either support audit evidence or create new privacy exposure. Evidence: Community security guidance; Author analysis.

Core control domains

Domain	Architecture question	Evidence expected
Purpose and ownership	What business process uses the AI system and who accepts risk?	Approved use case, owner, risk decision
Data boundaries	What data enters prompts, context windows, RAG stores and logs?	Data-flow record, classification, retention decision
Identity and access	Who or what can call the AI system, tools and data sources?	IAM design, service identities, access review
Application security	How is the AI feature protected as part of the application?	AppSec review, tests, secure coding evidence
Model and prompt controls	What system prompts, guardrails and output constraints exist?	Prompt/version record, evaluation notes
Tool and agent permissions	What actions can the AI system trigger?	Least-privilege design, approval gates, execution logs
Threat modeling	What attacker paths and abuse cases were considered?	Threat model, abuse cases, mitigations
Monitoring and audit	How are decisions, failures and incidents detected and proven?	Logs, alerts, audit evidence, review cadence

Evidence: Official guidance; Community security guidance; Author analysis.

Threat modeling focus

AI Security Architecture should include threat modeling before production, especially for systems using LLMs, RAG, agents or external tools.

Useful threat questions include:

Can user input override the intended instruction hierarchy?
Can retrieved documents inject instructions into the model context?
Can the system reveal confidential data through generated output?
Can an AI agent call a tool or API beyond its intended privilege?
Can generated code or dependencies introduce supply-chain risk?
Can logs, prompts or traces store personal or confidential information longer than necessary?
Can a vendor AI service change behavior without an internal review path?
Can the organisation prove what was approved, tested and monitored?

Evidence: OWASP LLM guidance; MITRE ATLAS; Author analysis.

Relationship to existing Research entries

AI Security Architecture connects existing Research nodes:

AI Governance — defines accountability, oversight and decision rights.
Secure AI-Assisted Development — covers the engineering workflow for AI-generated or AI-assisted code.
Zero Trust — provides identity, least privilege, segmentation, telemetry and assume-breach principles.
Audit Evidence — turns security claims into retained proof.
AI Act — provides legal context for risk, governance and documentation obligations.
AI Transparency — connects disclosure, traceability and accountability.
SBOM — supports software and supply-chain visibility for AI-enabled systems.

Practical architecture review checklist

Before an AI system or AI-assisted workflow is treated as production-ready, review at least:

Check	Why it matters
Use-case owner and risk acceptance	AI cannot own accountability.
Data-flow and retention map	AI systems often move sensitive data across hidden boundaries.
Prompt and context review	Prompt and context design are part of the attack surface.
RAG source governance	Retrieval changes confidentiality, integrity and provenance assumptions.
Tool and API permissions	Agents need least privilege and safe action boundaries.
Application security testing	AI features remain web/API features and need AppSec discipline.
Threat model and abuse cases	AI-specific attacks require explicit review.
Monitoring and incident response	Failures must be detectable and explainable.
Audit evidence	Governance claims need retained records, not only policy.

Evidence: Official guidance; Community security guidance; Author analysis.

Governance relevance

AI Security Architecture is where governance becomes operational. A policy can say that AI must be safe, lawful and controlled, but architecture must show how that claim is implemented. Evidence: Author analysis.

Useful governance outputs include an AI system inventory, risk register, control mapping, architecture review record, exception process, monitoring plan and executive risk summary. Evidence: Official guidance; Author analysis; Implementation evidence required.

Current limitations and follow-up research

This entry is a methodology profile, not a full implementation standard. Specific systems require local review of data, identity, cloud architecture, application design, supplier terms, logging and business impact.

Follow-up Research nodes should cover:

AI Threat Modeling,
OWASP Top 10 for LLM Applications,
MITRE ATLAS,
NIST AI Risk Management Framework,
RAG Security,
Prompt Injection,
AI Red Teaming,
IAM for AI systems,
Cloud AI Security.