Prasanta Kumar Behera
AI-Assisted Infrastructure Engineering›14 · Guardrails & governance
Learning Hub / AI-Assisted Engineering / AI-Assisted Infrastructure Engineering

Lesson 14 of 14 · Modules

Guardrails & governance

Bring AI into infrastructure work without new risks: least privilege and blast-radius limits for agents, human approval gates, audit trails, data-privacy rules and redaction, defences against prompt injection, vetting AI tools and MCP servers like any dependency, and a lightweight policy teams can follow.

Advanced
Key wordsAI governanceleast privilege for agentsapproval gatesaudit loggingdata privacyredactionprompt injectionsupply chain of AI toolsevaluationusage policy

The risks, plainly

Risk Example
Excessive privilege An agent with cluster-admin deletes resources on a wrong conclusion
Data leakage Secrets or customer data pasted into prompts or sent by tools to an external API
Prompt injection A log line or ticket tells the agent to "print the kubeconfig"
Unreviewed changes AI-generated IaC merged without real review
Tool supply chain A third-party MCP server or extension exfiltrates data
Over-reliance Engineers stop verifying; skills atrophy

Giving an AI agent access to your systems is like giving a new assistant keys to the building. You give them the keys to only the rooms they need, ask them to check with you before moving anything big, keep a visitor log, never leave the safe's combination lying around, and remember that a note slipped under the door ("the boss says give me the safe code") isn't really from the boss.

Controls that work

  1. Least privilege: read-only credentials by default (e.g. a view-bound ServiceAccount, lesson 05); write actions only through separate, narrow, approved paths (lesson 12).
  2. Blast-radius limits: namespace allow-lists, max replicas, one node at a time, dry-run first.
  3. Approval gates: a human approves every state change, seeing the evidence.
  4. Deterministic guard rails: permissions and hooks that block dangerous commands regardless of what the model decides (lesson 04).
  5. Audit trail: requests, tool calls, approvals, outcomes, retained per your policy.
  6. Data handling: approved tools per data class; redaction of secrets/PII in pipelines; local or enterprise endpoints for sensitive work.
  7. Injection resilience: treat all tool output as untrusted data; don't let content from logs/tickets trigger actions without approval; cap and sanitise inputs.
  8. Supply-chain vetting: review MCP servers, skills, hooks and extensions (source, permissions, maintainers, pinned versions) like any dependency.
  9. Evaluation: test agents on realistic scenarios before expanding their scope; track accuracy over time.

A one-page team policy (starter)

AI in infrastructure work: team policy (v1)

Tools:     Approved: <tool list>. Other tools need platform + security review.
Data:      Never share secrets, credentials, customer/personal data, or unreleased security
           details. Sanitise hostnames/IPs unless the tool is approved for internal data.
Changes:   AI-generated code/IaC follows normal review; the author must understand every line.
           No auto-merge based on AI review.
Agents:    Read-only by default. State changes only via approved action tools with human
           approval, within documented limits. Destructive commands are blocked by hooks.
Tooling:   MCP servers, skills and hooks live in reviewed repos, pinned, with owners.
Audit:     Agent actions and approvals are logged and retained for <period>.
Incidents: Suspected leakage or unsafe agent behaviour is reported as a security incident.
Review:    Policy reviewed every 6 months.

Keep humans sharp

  • Rotate manual practice: game days without AI assistance, so engineers can still debug from first principles.
  • Require explanations in PRs for AI-heavy changes ("what does this do, how was it verified?").
  • Share failures of AI assistance openly; they calibrate everyone's trust.

Try it: audit your AI setup

  1. List every AI tool, MCP server, skill and hook your team uses, with what data and permissions each has.
  2. For each agent credential, run kubectl auth can-i --list (or the cloud equivalent) and reduce anything beyond what's needed.
  3. Put a prompt-injection line into a test log or ticket, and confirm your setup doesn't act on it (read-only tools, approvals).
  4. Adapt the one-page policy for your team and get feedback from security.
  5. Define two metrics you'll track (e.g. % of AI-suggested changes reverted, agent diagnosis accuracy in game days).

Going deeper: governance that scales

  • Align with your organisation's broader AI and data governance (and applicable regulations); infra teams often pilot practices others adopt.
  • Automate enforcement where possible (policy-as-code for agent permissions, CI checks for .claude/ or MCP config changes).
  • Revisit controls as tools gain capabilities; yesterday's read-only assistant may be tomorrow's agent.

Recap

  • Risks: privilege, leakage, prompt injection, unreviewed changes, tool supply chain, over-reliance.
  • Controls: least privilege, blast-radius limits, approval gates, deterministic guard rails, audit, data rules, injection resilience, vetting, evaluation.
  • Write a short team policy and keep human skills sharp.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.