Chapter 5C defines the operational security system around enterprise AI: network controls, monitoring, audit, detection, incident response, red-team testing, recovery, governance, and the decisions required to keep security effective after deployment.
5C.1 Network and infrastructure security
Enterprise AI workloads should use explicit ingress, private service access where appropriate, controlled outbound routing, workload identity, encrypted storage, and segmented execution environments. Agents should not inherit unrestricted enterprise or internet access.
- Use separate environments and identities for development, test, and production.
- Restrict egress by destination, protocol, tenant, and workload.
- Use private endpoints for sensitive data and model services where available.
- Isolate high-risk code execution and file processing in disposable sandboxes.
- Protect orchestration and policy stores with high availability and strict administration.
5C.2 Security monitoring and detection
Security monitoring should correlate application, model, retrieval, policy, tool, identity, and network signals. Traditional indicators such as authentication failure remain important, but agentic systems add suspicious loops, repeated denied capabilities, abnormal context growth, cross-domain retrieval, and unusual outbound destinations.
| Detection signal | Possible condition |
|---|---|
| Repeated attempts to invoke denied tools | Prompt injection, agent misconfiguration, or malicious user |
| Sudden increase in context volume | Data harvesting, tool loop, or retrieval manipulation |
| Cross-tenant cache or memory access | Isolation failure |
| New external destination requested | Exfiltration or unreviewed integration |
| Approval followed by different action hash | Time-of-check/time-of-use violation |
| High rate of post-condition failures | Connector drift, target change, or model degradation |
| Model routing outside expected region | Policy or gateway failure |
5C.3 Audit evidence
Audit evidence should answer who initiated the task, which agent and version acted, what context and sources were used, which model processed the task, which policy decision applied, who approved the operation, what capability executed, and whether the intended post-condition was verified.
{
"trace_id":"tr_01J8...",
"initiator":"user_19482",
"agent":{"id":"payment-review-agent","version":"3.1"},
"sources":["invoice:INV-8821","contract:CT-991:v4"],
"model_deployment":"reasoning-enterprise-eu",
"policy":{"id":"payment-policy-v7","decision":"allow_with_approval"},
"approval":{"id":"ap_2201","approver":"user_7721","action_hash":"sha256:..."},
"capability":"erp.payment.prepare",
"operation_id":"op_44192",
"post_condition":"payment_draft_verified",
"outcome":"success"
}Audit stores require integrity controls, restricted access, retention rules, and privacy minimization. Full prompt content may be necessary for some investigations, but should not be exposed broadly or retained without purpose.
5C.4 Incident response
AI incident response extends conventional security response. The organization must be able to suspend an agent, revoke its credentials, disable one capability, block one model deployment, remove poisoned knowledge, stop active workflows, and preserve evidence independently.
| Incident | Immediate containment | Recovery |
|---|---|---|
| Prompt injection with tool attempts | Disable affected capability or agent route; preserve trace | Patch content controls, policy, evaluation, and source trust |
| Cross-tenant disclosure | Stop service, revoke tokens, isolate stores | Correct partitioning, rotate secrets, notify according to obligations |
| Compromised connector | Revoke workload identity and network access | Rebuild, verify target changes, reconcile operations |
| Poisoned knowledge source | Suspend indexing and retrieval from source | Restore trusted version and reprocess affected outputs |
| Unsafe model update | Roll back route or deployment | Expand evaluation and release controls |
| Unauthorized business action | Stop workflows, reverse or compensate action | Investigate identity, policy, approval, and connector chain |
5C.5 Security testing and red teaming
Security testing should cover normal application vulnerabilities and agent-specific abuse. Test direct and indirect injection, data extraction, tool escalation, identifier substitution, cross-tenant access, approval bypass, replay, duplicate writes, malicious files, external URLs, model fallback, and recovery.
Threat-model review, SAST, dependency scanning, policy tests, connector simulation, adversarial cases, red-team exercises.
Canary monitoring, detection rules, sampled review, drift, denied tool telemetry, incident feedback, periodic access review.
Red-team findings should become regression tests. A successful attack that is only documented, but not converted into a repeatable evaluation and control, will likely recur.
5C.6 Security governance
Security approval should be risk-tiered. Read-only assistants, draft-producing workflows, and autonomous high-impact agents require different gates. Governance should cover owners, threat model, data classification, identity, network path, tool inventory, evaluation, incident owner, and retirement plan.
5C.7 Security Architecture Decision Records
# ADR-SEC-009: Prohibit unrestricted outbound HTTP tools
Status: Accepted
Context:
Agents need access to selected public APIs and approved partner services.
A generic HTTP tool would permit SSRF, data exfiltration, and unreviewed destinations.
Decision:
Agents may use only destination-specific connectors registered in the capability catalog.
All outbound traffic passes through an authenticated proxy and destination allowlist.
Controls:
- Per-destination DNS and certificate validation
- Request and response schema validation
- DLP inspection
- Tenant and agent attribution
- Rate and data-volume limits
- Security telemetry and emergency block
Consequence:
New destinations require connector onboarding, but egress becomes governable and auditable.5C.8 Production security readiness checklist
5C.9 Summary
Chapter 5C turns security architecture into an operating capability. Network controls restrict reach. Monitoring and audit expose behavior. Incident response contains failures. Red-team testing converts unknown weaknesses into repeatable controls. Governance keeps the architecture effective as agents, models, and tools change.
Core conclusion: enterprise AI security is complete only when the organization can detect misuse, contain it quickly, recover business state, and prove what happened.