Design Security Controls for an Agentic AI Assistant

This is the synthesis of Phase 7, and the deliverable a GRC engineer owns for any agentic system: capability by capability, what may it do on its own, what needs a human, and what guardrails wrap each action. Your subject is Atlas, an internal operations-and-engineering assistant. Atlas can read internal docs, browse the web, spawn sub-agents to work through tasks, email customers, change production config, and issue refunds — a realistic, over-broad starting toolset. Your job is to right-size it.

For each capability, set the control posture — how much autonomy Atlas gets — and select the guardrails you would wrap around it. Match the posture to the risk: a high-risk action left autonomous is exactly the excessive-agency failure this module is about, and the summary will flag it if you do. There is a defensible answer for each; the reasoning is the point.

What to carry forward

Notice the shape of a good answer: postures escalate with risk. The low-risk read is autonomous; the untrusted-input and runaway capabilities are allowed but watched; the money, external, and production actions are gated on a human or denied outright. That gradient is the whole discipline — autonomy in proportion to how tightly the action is contained. And every cell has a reason and an artifact (the posture decision, the guardrail config, the approval log) that proves the control operates to an auditor.

That completes Phase 7. You can now take an AI system and translate "secure it" into specifics across the whole stack: its governance tier and obligations (7.1), its injection defenses (7.2), its access and authorization (7.3), and its agentic containment and RAG scoping (7.4) — each a control with evidence. The phase capstone puts it together end to end on a single system.