Security architecture begins by identifying what must be protected, where trust changes, who or what is acting, and which enterprise effects are possible. The objective is not to make the model “safe” in isolation. It is to make the entire system resilient to model error, adversarial input, identity abuse, data leakage, and unauthorized action.
5A.1 Security principles
Authenticate every principal, evaluate every capability request, and assume that context may contain untrusted instructions.
Give each agent only the tools, data, and resource scope required for one task.
Identity, policy, credentials, validation, approval, and audit must remain deterministic.
Enterprise AI security combines established application security with controls for probabilistic behavior, prompt-based manipulation, tool selection, model routing, context construction, and agent autonomy. A secure design assumes the model can be wrong, persuaded, confused, or exposed to malicious content.
5A.2 Security reference architecture
No individual control is sufficient. Content filtering cannot replace authorization. Strong identity cannot prevent unsafe tool parameters. A policy engine cannot detect a compromised connector. The architecture therefore uses independent layers so that one failure does not automatically become a business action.
5A.3 Protected assets
| Asset | Security concern | Examples |
|---|---|---|
| Enterprise data | Confidentiality, integrity, residency | Customer, employee, financial, operational, legal records |
| Identity and authority | Impersonation, privilege escalation, attribution | User claims, agent identities, approvals, delegated scope |
| Business capabilities | Unauthorized or unsafe side effects | Payments, account changes, production operations, communications |
| Models and prompts | Manipulation, extraction, poisoning, misuse | System instructions, routing policy, safety configuration |
| Knowledge and memory | Cross-tenant leakage, staleness, injection | Indexes, embeddings, summaries, session memory |
| Evidence and logs | Tampering, over-collection, privacy | Traces, approvals, tool outputs, evaluation records |
5A.4 Trust boundaries
A trust boundary exists whenever identity, ownership, data classification, administrative control, or network policy changes. Typical boundaries include user device to enterprise gateway, enterprise network to model provider, orchestrator to connector, connector to target system, and one tenant or business domain to another.
| Boundary | Required controls |
|---|---|
| User to AI gateway | Strong authentication, session integrity, rate limits, tenant binding |
| Gateway to model | Approved endpoint, encryption, data classification, region policy |
| Knowledge source to context | ACL preservation, provenance, injection scan, freshness |
| Agent to capability | Tool allowlist, policy decision, schema validation |
| Connector to target system | Scoped workload identity, network policy, audit, verification |
| Tenant to tenant | Data, memory, cache, logs, quotas, and identity isolation |
5A.5 Identity and access architecture
Enterprise AI introduces a chain of actors: initiator, application, agent, orchestrator, connector, and target workload. A secure architecture preserves each identity rather than collapsing the chain into a shared API key.
{
"initiator": {"subject":"user_19482","tenant":"enterprise-eu","mfa":"phishing-resistant"},
"agent": {"id":"finance-review-agent","version":"3.2","owner":"Finance Operations"},
"delegation": {"mode":"on_behalf_of","actions":["invoice.read","payment.prepare"],"expires_in":300},
"target": {"system":"erp-core","resource":"invoice:INV-8821"},
"policy": {"risk_tier":"high","approval_required":true}
}Agent identities require owners, sponsors, lifecycle state, approved tools, model policy, environment scope, and access reviews. Short-lived credentials should be issued at execution time. Secrets should never appear in prompts, model-visible configuration, agent memory, or tool descriptions.
5A.6 Zero Trust for AI systems
- Assume all retrieved content can contain malicious instructions.
- Authenticate users, workloads, agents, and connectors independently.
- Authorize every business capability request, not only the initial session.
- Use private connectivity or controlled egress for protected workloads.
- Continuously evaluate device, tenant, role, agent, risk, and resource context.
- Fail closed when identity, policy, approval, or target state cannot be verified.
Security boundary: the model may recommend a capability, but it must not mint its own authority.
Authorization remains an external deterministic decision based on trusted claims and current policy.
5A.7 Security foundation checklist
5A.8 Summary
Chapter 5A establishes the security foundation: protected assets, trust boundaries, identity, delegation, and Zero Trust. These controls define who or what is acting and prevent AI convenience from erasing enterprise authority.
Core conclusion: secure enterprise AI begins with explicit identity and trust boundaries, not with prompt filtering.