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…
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
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
- 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.
- 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.
- 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.
- 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.
- 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).
What You'll Accomplish
Design an AI/LLM usage-governance program — inventory, model registry, approval workflow, and a real shadow-AI discovery mechanism — that would actually surface ungoverned AI use, not just document a policy
Apply adversarial thinking to an MCP-based AI agent: design a concrete prompt-injection/jailbreak test and a per-tool-call authorization and containment mechanism
Correctly scope AI-governance and runtime-security work against adjacent functions (GRC, Data Security, Identity, Infrastructure) without overreaching into their territory
Design at least one CI/CD guardrails-as-code element (automated scanning with auto-block, or SBOM generation) consistent with a secure-SDLC program
Show production/program-ownership judgment: an incident runbook for a live guardrail precision problem, appropriate to a leadership role that owns this in production
Communicate technical security and AI-governance decisions in a way an engineer, a GRC partner, and a CIO can each act on
How Your Work Will Be Scored
What to Submit
Upload 1 — AI Governance & Agent Runtime Security Design
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Your working design as a document (Markdown, PDF, or a clearly formatted Word/Google doc). It must cover:
- An AI/model inventory and AI-BOM structure, plus a model-registry approval workflow with at least one named gate before a tool is used in production
- A concrete shadow-AI discovery mechanism, and what happens once an ungoverned tool is found (a triage path, not just "flagged")
- At least one specific prompt-injection or jailbreak test case for the MCP-based support agent, tied to its actual tool set (loyalty lookup, redemption, refund issuance)
- A per-tool-call authorization and containment design for the agent runtime — what stops it from taking an action it shouldn't, and what happens if it does anyway
- At least one CI/CD guardrails-as-code element: automated scanning (SAST/DAST/SCA/secrets) with a stated auto-block rule, or SBOM generation tied to a concrete downstream use
- A brief statement of how your design respects the stated boundaries with GRC, Data Security, Identity, and Infrastructure
You do not need to build software or deploy infrastructure. A structured written design is sufficient. Include a brief note at the top explaining how the document is organized.
Sign in to upload files
Upload 2 — README
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Section A — Design Rationale (300–500 words)
- Why did you design the AI-governance discovery mechanism the way you did? What did you consider and reject?
- Which prompt-injection/jailbreak test case did you choose for the agent, and why does it matter for this specific tool set?
- What does a flagged event look like in your design (a shadow-AI finding, or a blocked/contained agent action), and what happens next?
- What are the most important things you'd add or change with more time?
Section B — Production Ownership
Part B1 — Incident Runbook: Two weeks after your CI/CD guardrails go live, the auto-block rule starts flagging a legitimate release pipeline as a critical finding, delaying a scheduled deployment. Write a runbook for the on-call engineer who gets the alert. Include at least 3 concrete, actionable steps. The first step should not be "escalate to the rule author."
Part B2 — AI Reasoning (complete without AI assistance): Describe a scenario where an AI assistant would give you a plausible but incorrect AI-governance or agent-security design for this kind of scenario — and explain specifically how you would catch it before relying on it.
Section C — AI Usage Log (Mandatory)
This is not a trick. We want to see how you work with AI — not whether you used it. For each significant interaction with an AI tool, briefly note: what you asked the AI to help with / what it gave you / what you kept, changed, or rejected — and why. Three interactions documented is sufficient.
Sign in to upload files
Upload 3 — Video Walkthrough (8–10 minutes)
Format: .mp4, .mov, .webm
Record as MP4 or MOV and upload directly on the Provn platform as a separate file. Structure your video as follows:
- Summary (60 seconds): The problem, your approach, and your recommendation in one minute
- Design walkthrough (3–4 minutes): Walk through your AI-governance program design and your agent runtime security design, and one key trade-off you made
- Section B walkthrough (2 minutes): Walk through your incident runbook (Part B1) and your AI reasoning answer (Part B2)
- Mandatory AI question (1–2 minutes): 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.
- Reflection (30–60 seconds): What would you do differently or add with more time?
Speak naturally, as if briefing your CIO directly. Communication is assessed on clarity of technical ideas and logical structure for a broad audience — not verbal polish, accent, or filler words.
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page