AI Governance & Agent Runtime Security Design

Description

You're joining Arrivia as Manager, Application & AI Security, reporting to the EVP of IT & Security. You hold the central AI-governance mandate and own DevSecOps golden pipelines, application security testing, and MCP/AI-agent runtime security — making safe AI adoption the default rather than a review bottleneck.

The problem you've been handed:

Two things are happening at once, and your new team of three is behind on both.

First: engineers across Arrivia's brands have been using ChatGPT, GitHub Copilot, and other AI coding tools for months with no formal governance. There's no inventory of which tools are in use, no registry of what's been approved, and no visibility into whether anyone has pasted member PII or loyalty-account data into a public LLM. Leadership wants a usage policy and a discovery mechanism — not a document nobody reads.

Second: the Contact Center team has built an MCP-based AI support agent that connects to three internal tools — a loyalty-account lookup tool, a redemption-processing tool, and a refund-issuance tool — so support agents can resolve member requests faster. It's scheduled to go live with real members in three weeks. Nobody has red-teamed it, and nobody has designed authorization for what happens when the agent calls one of those tools.

Your manager needs a design document — not code, not a slide deck of buzzwords — covering both problems, that an engineer, a GRC partner, and the CIO could each act on.

Constraints to Consider

1. You cannot request new raw data fields or new tooling budget. Work with the AI agent and tool set described above — this is a constraint on control design, not an invitation to redesign the agent's architecture.
2. You do not own the AI management-system program or its compliance evidence. GRC owns the ISO/IEC 42001 and NIST AI RMF "Govern" program and evidence. Your scope is implementing the technical controls (registry, discovery, runtime guardrails, red-teaming) that GRC's program will point to — not writing GRC's audit narrative.
3. You do not own prompt/response DLP or training-data controls. Data Security owns those. Your scope for the AI agent is runtime authorization, containment, and red-teaming of the agent itself — not what the model is allowed to say or what data it was trained on.
4. You do not own Identity or Infrastructure's platforms. Identity owns PIM/PAM — you consume it for pipeline and application entitlements, you don't redesign it. Infrastructure owns IaaS/AI-ML hosting — you own the application/PaaS layer and pipeline guardrails on top of it.
5. Touch all required areas — don't go deep on one at the expense of the rest. You have 45 minutes total, including video. Breadth across the required areas, calibrated to what's achievable in that time, is what's being tested — not exhaustive depth on a single area.

AI Usage Guidance

We expect you to use AI tools. We evaluate how you use them — not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.

The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.

Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.

Speak naturally, as if briefing your CIO directly. Communication is assessed on how clearly you translate technical controls for a broad audience — not verbal polish, accent, or filler words.

Submission: Upload each deliverable as a separate file directly on the Provn platform: your AI Governance & Agent Runtime Security Design, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).