18.19 — Cloud DevOps Security: Connecting Infrastructure to AI Security

Relationship to Part 9: Part 9 taught AI-specific security in depth (prompt injection, excessive agency, data exfiltration, authn/authz, secrets, tenant isolation) — this chapter does not re-teach it. This chapter is the infrastructure security layer underneath Part 9's application-layer concerns, and — its actual purpose — the explicit bridge showing how each connects to the other, since a real security review (and a real attacker) doesn't respect the boundary between "infrastructure security" and "AI security" the way this handbook's chapter organization does.

1. What is it?

A synthesis of the DevOps/infrastructure security practices already introduced piecemeal across 18.1–18.18 — least privilege, network segmentation, secrets management, encryption, container/supply-chain security, audit logging — reviewed together as one coherent posture, and explicitly connected to Part 9's AI-specific risks: a compromised or over-permissioned piece of infrastructure is very often how a prompt injection or excessive-agency incident (Part 9.1/9.2) becomes a real, damaging breach rather than a contained, low-impact event.

2. Why does it exist?

Part 9 correctly focused on AI-specific attack surface (what can go wrong because the system uses an LLM/agent). This chapter exists because the blast radius of an AI-specific failure is determined by the infrastructure security decisions in 18.1–18.18 — an excessive-agency incident (Part 9.2) where an agent's tool call goes wrong does far less damage if that tool's IAM role (18.3) is scoped to exactly one S3 prefix than if it inherited broad account permissions "to make development easier."

3. What problem does it solve?

It solves "our AI-specific security review (Part 9) looks solid — are we actually secure," by insisting the infrastructure layer be reviewed too, since a real incident's severity is a product of both layers together, not either one alone.

4. How does it work internally?

The infrastructure security posture, reviewed as one system

Pulling together what's already been established, deliberately without re-deriving any of it:

IDENTITY (18.3):        IAM roles, not static credentials; least
                         privilege scoped to specific actions/ARNs
NETWORK (18.2/18.5):     public/private subnet segmentation; security
                         groups by ID; NAT for outbound-only access
DATA (18.4/18.5):        encryption at rest and in transit; Secrets
                         Manager, not plaintext credentials
CONTAINERS (18.7):       non-root users; scanned images (Trivy/Grype);
                         no secrets baked into image layers
ORCHESTRATION (18.9):    Kubernetes RBAC scoped to actual need; secrets
                         encryption at the etcd layer verified, not assumed
SUPPLY CHAIN (18.8):     image signing/provenance (cosign); least-
                         privilege CI pipeline credentials
AUDIT (18.5):            CloudTrail for infrastructure API calls —
                         DISTINCT from an application-level audit log

Each of these is necessary but, on its own, insufficient — a system with perfect network segmentation but an over-permissioned IAM role, or perfect IAM but secrets baked into a container image, is not actually secure; the review has to check all of them together.

The explicit bridge: how infrastructure security determines AI-incident blast radius

This is this chapter's actual, distinct contribution — not a repeat of Part 9, but the connective reasoning Part 9 deliberately left to the infrastructure layer:

Part 9.1 (Prompt Injection): an attacker manipulates the LLM into
  issuing an unintended tool call or generating unintended output.
  → INFRASTRUCTURE QUESTION: what can that tool call actually DO?
    If the tool's underlying IAM role (18.3) or database credentials
    are scoped to exactly what the LEGITIMATE use case needs (least
    privilege), a successful injection's blast radius is bounded by
    that scope — it cannot escalate beyond what the infrastructure
    itself permits, regardless of how convincing the injection was.

Part 9.2 (Excessive Agency / confused deputy): an agent is tricked into
  misusing its own legitimate permissions.
  → INFRASTRUCTURE QUESTION: are those permissions scoped narrowly
    (18.3's least privilege) and are side-effecting actions
    idempotent/rate-limited (18.4/18.12's patterns) so a single
    successful manipulation can't cause unbounded, repeated damage?

Part 9.3 (Data Exfiltration): sensitive data leaves the system via an
  agent's output or a tool call.
  → INFRASTRUCTURE QUESTION: is EGRESS network traffic itself
    restricted (18.2's NAT/security-group control over what a
    private-subnet resource can actually reach outbound), providing a
    network-layer backstop even if an application-layer control fails?
    A perfectly-isolated agent sandbox (Part 9.6) with unrestricted
    internet egress still permits exfiltration — network-layer egress
    control is a DISTINCT, necessary layer, not redundant with
    application-layer output filtering.

Part 9.4 (AuthN/AuthZ): a user or service accesses something it
  shouldn't.
  → INFRASTRUCTURE QUESTION: does Kubernetes RBAC (18.9) or IAM (18.3)
    ALSO enforce a matching boundary, so an application-layer
    authorization bug doesn't leave the infrastructure layer as the
    only remaining check — defense in depth across BOTH layers, not
    reliance on either alone?

Part 9.5 (Secrets): a credential is exposed.
  → INFRASTRUCTURE QUESTION: is it scoped narrowly (18.3's least
    privilege again) and rotatable (Secrets Manager, 18.5) so exposure
    has a bounded window and bounded blast radius, rather than being a
    permanent, account-wide compromise?

Part 9.6 (Tenant Isolation / Sandboxing): one tenant's data or execution
  must not affect another's.
  → INFRASTRUCTURE QUESTION: does the isolation boundary (namespaces,
    18.9; network policies, 18.2; dedicated resources for strict
    requirements) actually match the STATED isolation requirement, or
    is a soft, convention-only boundary (e.g., a shared namespace with
    no network policy) being presented as equivalent to a hard one?

The pattern across every row: Part 9 identifies the AI-specific failure mode; this chapter asks what the infrastructure does once that failure mode occurs — the difference between a contained incident and a severe breach is, in a large fraction of real cases, decided at exactly this infrastructure layer, not at the application layer where the AI-specific mitigation (Part 9's chapters) primarily operates.

Model access control — a genuinely infrastructure-layer AI security concern

One AI-specific concern that lives squarely at the infrastructure layer, not Part 9's application layer: which identities/roles can actually invoke which models, and at what cost ceiling. IAM policies (18.3) scoping which service/role can call which model endpoint (relevant directly for a self-hosted model, 18.16, where the model endpoint is your own infrastructure) or which application component holds which provider API key (Secrets Manager, 18.5) both function as infrastructure access controls specifically on model usage — distinct from, and complementary to, the application-level "which user can ask the AI to do what" controls Part 9.4 already covers.

5. Simple mental model

If Part 9 is the security of what happens inside the building (can someone trick an employee into doing something they shouldn't), this chapter is the building's actual physical security — the locks, badge access, and perimeter fencing that determine how far someone who does succeed at tricking an employee can actually get before hitting a wall. Both matter; neither substitutes for the other.

6. Real-world example

A prompt injection (Part 9.1) successfully manipulates the Enterprise AI Assistant's document-summarization agent into attempting to call a tool that reads a different customer's documents than the one it was scoped to. Because the tool's underlying IAM role (18.3) grants s3:GetObject scoped to exactly arn:aws:s3:::acme-docs-prod/tenant-A/* (not a broader wildcard), and network egress from the agent's execution environment is restricted (18.2's egress-control point), the attempted call fails at the infrastructure layer regardless of how convincing the injection was at the application layer — a real incident, correctly contained to "attempted and blocked," specifically because the infrastructure security posture (this chapter) backstopped the application-layer defense (Part 9) rather than the two layers leaving an uncovered gap between them.

7. Architecture diagram

Part 9's application-layer defensesprompt-injection detection, output filtering, agent permission scoping, tenant-aware queries

This chapter's infrastructure-layer backstopIAM least privilege (18.3), network egress control (18.2), Kubernetes RBAC (18.9), secrets scoping/rotation (18.5), tenant isolation boundary (18.9), audit trail via CloudTrail (18.5)

Bounded, contained incidentNOT an unbounded, account-wide breach

8. Production considerations

• Run infrastructure security review (this chapter's checklist) and AI-specific security review (Part 9) together, explicitly asking the bridge question (section 4) for each Part 9 risk — not as two disconnected review exercises.
• Treat network egress control as a required, distinct layer even when application-layer output filtering (Part 9.3) is already in place — neither substitutes for the other.
• Verify Kubernetes secrets encryption at the etcd layer explicitly (18.9's flagged point) rather than assuming a cluster's default configuration handles it.

9. Common mistakes

• Treating Part 9's application-layer AI security as sufficient on its own, without checking that infrastructure permissions actually bound the damage a successful attack could do.
• Assuming a perfectly-isolated sandbox (Part 9.6) is complete without also restricting its network egress — a common, serious gap.
• Reviewing infrastructure security and AI security as two entirely separate exercises with no explicit cross-referencing, missing exactly the compounding risk this chapter addresses.

10. Security considerations

This entire chapter is a security chapter — its specific, additional contribution beyond Part 9 is the explicit infrastructure-to-AI-risk bridge (section 4), which is easy to miss when the two topics are taught (as this handbook necessarily does, for teachability) in separate parts.

11. Performance considerations

Least-privilege IAM policies and network segmentation (18.2/18.3) add negligible performance overhead relative to their security value — the common myth that "tight security is slow" doesn't hold for these specific controls, which are evaluated at request/connection setup, not per-token during inference.

12. Cost considerations

Security controls here are generally low-cost relative to their risk reduction (an IAM policy costs nothing; network segmentation costs little beyond the NAT Gateway cost already accounted for in 18.2/18.18) — the real cost of skipping them is a potential incident's cost, not a line item on a monthly bill, making this an unusually clear case where underinvestment is a false economy.

13. When to use it

Every production AI system needs both layers reviewed together — this chapter's bridge reasoning should be part of any security review, not an optional addition.

14. When NOT to over-apply it

A local prototype (Part 13.2) doesn't need a full infrastructure-security review — apply this chapter's rigor once real customer data or production traffic is in scope, matching security investment to actual risk exposure per stage of the FDE lifecycle (Part 13.1).

15. Alternatives and trade-offs

There's no real alternative to defense-in-depth here — relying on either layer alone (Part 9's application controls, or this chapter's infrastructure controls) leaves a real, demonstrated gap; the "trade-off" is entirely about how much review rigor and ongoing maintenance effort (periodic IAM/RBAC audits, 18.3/18.9) an organization commits to sustaining both layers together over time.

16. Practical example — a bridge-question review template

# Infrastructure-Security Bridge Review (run alongside Part 9's review)

For EACH Part 9 risk category, answer this chapter's bridge question:

| Part 9 risk           | Infrastructure control that bounds its blast radius | Verified? |
|------------------------|-------------------------------------------------------|-----------|
| Prompt injection        | IAM role scope for the tool the injection could trigger | [ ]       |
| Excessive agency         | Rate limits / idempotency on the side-effecting action  | [ ]       |
| Data exfiltration        | Network egress restriction, independent of output filter| [ ]       |
| AuthN/AuthZ gap           | Kubernetes RBAC / IAM boundary matching app-layer intent | [ ]       |
| Secret exposure           | Scope + rotation via Secrets Manager                    | [ ]       |
| Tenant isolation failure  | Namespace + network policy actually enforced             | [ ]       |

17. Production-quality example — least-privilege IAM for an agent's tool

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentToolScopedToOneTenantPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::acme-docs-prod/tenant-${aws:PrincipalTag/TenantId}/*"
    }
  ]
}

Using a policy variable (${aws:PrincipalTag/TenantId}) tied to the calling role's own tag, rather than a hardcoded prefix, is what makes this pattern actually scale correctly across many tenants (Part 9.6) without either a combinatorial explosion of per-tenant policies or a dangerously broad shared policy — directly implementing section 4's bridge reasoning for the prompt-injection and tenant-isolation rows together in one concrete mechanism.

18. Short exercise

Take the excessive-agency financial-transfer tool example from Part 9.2 (a $500 autonomous-transfer cap with no velocity limiting) and design the infrastructure-layer backstop this chapter argues for — specifically, what rate-limiting (18.14's Redis-based pattern) or idempotency/replay protection (18.4/18.12) at the infrastructure layer would prevent the "ten rapid $499 transfers" smurfing gap Part 9.2 identified, independent of any additional application-layer fix.

19. Interview questions

• Why isn't Part 9's application-layer AI security sufficient on its own, without an infrastructure security review alongside it?
• Walk through how an over-permissioned IAM role turns a contained prompt- injection attempt into a severe breach.
• Why does network egress control matter even when output filtering (Part 9.3) is already in place?
• What's the infrastructure-layer analogue of Part 9.6's tenant isolation, and how do you verify it's actually enforced, not just assumed?

20. FDE/customer scenario

A customer's security team asks: "We've reviewed your AI-specific security controls and they look good — what about the infrastructure underneath it?" A strong response walks through this chapter's bridge table (section 16) explicitly for their specific architecture — showing, for each Part 9 risk category, exactly which infrastructure control bounds its blast radius if the application-layer defense is ever bypassed — demonstrating defense-in-depth concretely rather than pointing only to the AI-specific controls already reviewed.

---

Key takeaways

• Infrastructure security (this chapter) determines the blast radius of an AI-specific security failure (Part 9) — the two layers are complementary, and neither is sufficient reviewed alone.
• A perfectly-isolated sandbox with unrestricted network egress still permits exfiltration — network-layer egress control is a distinct, necessary layer independent of application-layer output filtering.
• Least-privilege IAM/RBAC, applied to the exact tool or role an AI- specific attack would exploit, is the single most direct infrastructure backstop for nearly every Part 9 risk category.

Things you should be able to explain

• The specific infrastructure control that bounds the blast radius of each of Part 9's major AI-security risk categories.
• Why network egress control and application-layer output filtering are both necessary, neither sufficient alone.

Things you should be able to build

• A bridge-question review template connecting Part 9's risks to concrete infrastructure controls.
• A tenant-scoped, least-privilege IAM policy using a principal tag variable rather than a hardcoded per-tenant policy.

Common mistakes

• Treating Part 9's application-layer review as sufficient without an infrastructure-layer review alongside it.
• Isolating execution (sandboxing) without also restricting network egress.
• Reviewing infrastructure and AI security as two disconnected exercises.

Recommended next chapter

20-multi-cloud-concepts.md