Enterprise AI Security Architecture — Part II | AetherStaff
AAetherStaff
Enterprise Agent Engineering · Security Reference
Chapter 05B · Security Architecture · AI Threats

AI-specific threats: prompt injection, tools, and data

Part II addresses the attack surface created by model reasoning, untrusted context, broad tools, agent handoffs, and generated outputs.

Chapter 5B focuses on the AI-specific attack surface: prompt injection, malicious context, insecure tool use, data exfiltration, model misuse, agent-to-agent propagation, and unsafe output handling. The objective is to contain model manipulation before it reaches enterprise state.

5B.1 Threat landscape

ThreatAttack objectivePrimary control family
Direct prompt injectionOverride instructions or bypass intended workflowTask constraints, policy, tool restrictions, output validation
Indirect prompt injectionUse documents, email, web, or tickets to manipulate the agentContent trust labels, context isolation, capability authorization
Excessive agencyExploit broad tools, permissions, or autonomyLeast privilege, bounded capabilities, approval, limits
Sensitive data disclosureExtract protected context, memory, prompts, or recordsACL-aware retrieval, DLP, field filtering, egress control
Insecure output handlingTurn generated content into code, query, command, or injectionSchema validation, escaping, domain validation, safe adapters
Knowledge poisoningInsert false or malicious content into retrieval sourcesSource approval, lineage, versioning, integrity monitoring
Agent propagationSpread malicious context or decisions across agentsContext isolation, structured handoffs, independent policy

5B.2 Prompt injection defense

Prompt injection is not solved by a stronger system prompt. The architecture must assume that model instructions and untrusted content share the same interpretation channel. The defense therefore limits what the model can access and what downstream systems will accept.

Prompt injection containmentBreak the path from malicious content to side effect
Malicious document / email / page
Content classification
Context isolation
Model reasoning
Tool allowlist
Policy decision
Schema validation
Approval / verification
  • Mark source trust and authority explicitly.
  • Separate instructions from retrieved evidence in the context structure.
  • Do not pass entire documents when only a relevant section is needed.
  • Do not let retrieved content modify tool permissions or policy.
  • Require independent authorization for every side effect.
  • Log suspicious instructions and denied capability attempts as security events.

5B.3 Tool and capability security

Tool security is where AI-specific manipulation becomes conventional enterprise risk. The safest tool is a narrow business capability with explicit schema, owner, resource scope, risk tier, idempotency, and post-condition verification.

Tool patternRiskPreferred replacement
Arbitrary SQLData exfiltration, mutation, expensive queriesApproved query service or semantic API
Shell executionSystem compromise and lateral movementVersioned runbook capability
Unrestricted HTTPSSRF, data exfiltration, malicious destinationsDestination-specific connector with allowlist
Broad file accessSecret and personal-data disclosureScoped document retrieval service
Raw administrative APIExcessive functionality and permissionsBusiness-level operation with policy

Security rule: never make a dangerous primitive safe only by describing acceptable use in natural language.

Remove or isolate the primitive and expose a constrained capability instead.

5B.4 Data protection and exfiltration controls

BEFORE
Filter retrieval

Apply tenant, role, field, classification, purpose, and geography controls before context assembly.

DURING
Minimize context

Pass only relevant fields and sections; avoid broad record dumps and secret material.

AFTER
Control output

Use DLP, redaction, egress policy, response classification, and safe destination rules.

Data-loss prevention should cover prompts, retrieved context, tool parameters, model outputs, logs, and external connectors. The model should not be trusted to decide whether information is confidential. Classification and field-level rules must be deterministic.

5B.5 Model and supply-chain security

Model deployments, agent frameworks, plugins, MCP servers, container images, libraries, and prompt assets are part of the software supply chain. Organizations should maintain approved registries, signed artifacts, dependency inventories, vulnerability scanning, and change control.

Model providers and deployments are approved per task and data class.
Agent and prompt versions are immutable and traceable.
Third-party tools and MCP servers have named owners and security reviews.
Images and dependencies are scanned and signed.
External model or tool changes trigger regression evaluation.
Emergency revocation can disable a model, agent, or capability independently.

5B.6 Agent isolation and secure handoffs

Multi-agent systems should use separate context and permission scopes. Agents exchange structured results, source references, and task metadata—not unrestricted conversation histories. Each receiving agent should re-evaluate policy for its own capabilities.

Structured agent handoff
{
  "from_agent":"incident-analysis-agent",
  "to_agent":"change-planning-agent",
  "task_id":"task_88421",
  "result":{"root_cause":"configuration regression"},
  "evidence_refs":["trace:tr_441","deployment:rel_822"],
  "allowed_next_capabilities":["service.change.prepare"],
  "sensitive_fields_redacted":true,
  "policy_decision_id":"pd_10933"
}

5B.7 Secure output handling

Generated content must be treated as untrusted input to downstream systems. HTML must be escaped, URLs validated, SQL parameterized, files scanned, and structured payloads checked against schemas and business rules. Never execute generated code or commands directly in a privileged environment.

OutputRequired handling
HTML / MarkdownSanitize active content, scripts, links, and embedded resources
SQLPrefer query API; otherwise parameterize, restrict, and run read-only
CodeStatic analysis, sandbox, tests, human review, signed pipeline
CommandsMap to approved runbooks; prohibit arbitrary execution
JSON / YAMLSchema, type, range, identifier, and domain validation
FilesType verification, malware scan, content inspection, size limits

5B.8 AI-specific security checklist

Retrieved content is treated as untrusted unless explicitly approved.
Source trust and authority are visible in context metadata.
Prompt injection cannot change identity, policy, or tool scope.
Agents see only capabilities authorized for the current task.
Raw administrative primitives are removed or strongly isolated.
All model outputs are validated before downstream use.
DLP covers context, output, logs, and connectors.
Multi-agent handoffs are structured and policy-scoped.
Third-party models, tools, and dependencies are lifecycle-managed.
Suspicious prompts and denied tool requests create security telemetry.

5B.9 Summary

Chapter 5B contains the AI-specific threat surface by limiting context, agency, tools, outputs, and agent propagation. Prompt injection is treated as an expected input condition, not an exceptional model failure.

Core conclusion: the safest response to model manipulation is a system in which the model never possesses enough authority to turn manipulation directly into enterprise impact.