Marcus, thanks for having me. I live at the intersection of cloud platforms and real-world engineering, which means I’ve seen the upside of AI—faster code, tighter feedback loops—alongside the rising tide of shadow AI. With half of workers already using unapproved AI and over 70% in the UK doing the same, often weekly, we’re past the “if” and deep into the “how” of governing it. Today I’ll share how to close the visibility gap in software development with pragmatic controls, process-centric governance, and change management that respects developer momentum.
With half of workers using unapproved AI tools—and over 70% in the UK, many weekly—what business drivers are fueling this behavior, and where do you see the biggest hidden costs? Please share a concrete example with metrics on productivity gains versus security or compliance exposure.
The pull is speed-to-outcome: developers feel immediate relief from toil, and leaders see cycle time compressing without waiting on procurement or enablement. When half of workers already use unapproved tools—and in the UK, over 70%, with more than half using them weekly—it signals unmet demand for faster research, code generation, and documentation. The hidden costs surface in audit gaps, data residency violations, and code provenance uncertainty that slows releases later, especially when compliance can’t validate where prompts, code, and vendor logs went. I’ve watched a team lean on unsanctioned models to accelerate prototype spikes, then spend multiple sprints untangling data lineage because prompts and outputs weren’t centrally logged—what felt like a shortcut became rework during security review.
AI agents often mix private data access, external communications, and exposure to untrusted prompts. How do you break this “lethal trifecta” in practice? Walk through specific controls at each layer and the trade-offs teams must accept.
I separate capabilities so no single agent holds all three at once. For data, scope access to task-specific datasets with read-only, least-privilege credentials and short TTLs; for external comms, force egress through a broker that enforces allowlists and strips sensitive headers; for prompt intake, sandbox untrusted context and inject defensive system prompts that disable tool use unless risk checks pass. Runtime isolation is critical: per-process network policies, write fences on critical repos, and execution sandboxes for tools like package managers and shells. The trade-off is a small hit to convenience—one agent becomes a team of constrained micro-capabilities—but you dramatically blunt prompt injection and data exfiltration risk without blocking legitimate work.
Developers may paste code, credentials, or design docs into external models. What guardrails most effectively stop sensitive data egress without killing velocity? Describe your redaction, tokenization, and policy-enforcement steps, plus any measurable leakage reduction you’ve achieved.
Put a policy-aware proxy in front of all AI endpoints and wire IDE extensions to it by default. At the proxy, run layered detectors for code secrets, customer identifiers, and architecture metadata; then auto-redact with placeholders or tokenize fields that must persist across turns, so context stays useful while sensitive bits never leave. Enforce policy-as-code: deny for high-risk classes, transform for medium, and allow with tagging for low, and log every decision for audits. With half of workers already on unapproved tools, even partial migration to this path yields immediate risk reduction because sensitive strings stop at the boundary while developers keep their flow.
Traditional tools like CASBs, SaaS discovery, and endpoint monitoring miss AI tucked inside engineering workflows. How do you gain visibility into agents running on personal laptops or with personal API keys? Outline the technical signals you track and how you reconcile them with privacy concerns.
I focus on control points developers already traverse: IDE plugins, CI runners, and the AI access layer. Signals include model endpoint calls, prompt/response metadata (size, routes, policy actions), tool-use events from agents, and code provenance tags flowing into commits and build artifacts. For personal hardware or keys, we encourage bring-your-own-tool via an org-issued routing key that unlocks higher rate limits and features; most developers adopt it voluntarily, which shifts traffic into governed paths. Privacy-wise, we log structured metadata and policy outcomes, not raw code or full prompts, unless a severity threshold is tripped—developers see exactly what’s captured, which builds trust.
What does a centrally managed AI access layer look like in detail? Explain routing, key management, model cataloging, dataset scoping, and audit logging. How do you roll it out incrementally and prove value within the first 30 days?
Think of it as an API gateway for AI: one endpoint, pluggable backends, and policy at the edge. Routing picks a model from a catalog based on task, data sensitivity, and cost controls; key management rotates provider keys centrally and issues scoped, short-lived client tokens; dataset scoping attaches signed context packages so models see only what they should. Audit logging records who used which model, when, with which policy transforms, and what artifacts were produced—all tied to build/test/release objects. In 30 days, start with read-only logging and redaction on the top two IDEs, migrate the CI assistant to the gateway, and publish weekly usage and policy-action reports; with over half already using tools weekly, this immediately replaces shadow paths with governed ones.
Process-level network controls can confine agents to approved services. What’s your step-by-step playbook for implementing allowlists, egress filtering, and just-in-time credentials? Share any incident where this containment blunted a prompt injection or data exfiltration attempt.
First, map agent toolchains, then assign each agent a distinct runtime identity. Second, enforce per-process allowlists so only model endpoints and approved internal APIs are reachable; route all traffic through an egress proxy that strips tokens, enforces TLS pinning, and blocks DNS for non-approved domains. Third, issue just-in-time credentials via short-lived tokens bound to the process identity and task. We’ve seen a prompt injection try to make an agent curl a random domain; the process-level allowlist and egress filter blocked the call, logs showed the attempted domain, and JIT credentials prevented any token reuse—containment turned a scary moment into a teachable log entry.
How do you measure and mitigate AI-generated code risks entering repositories? Describe your pipeline checks—SAST, dependency scanning, provenance attestations, and AI-output flags—and the thresholds that trigger human review.
Tag AI-originated diffs at the IDE and carry that flag into commits and pull requests, so reviewers have context. In CI, run SAST and dependency scans, then require provenance attestations that include which model and policy path were used; if issues intersect with AI-flagged changes, auto-escalate. Define thresholds: certain vulnerability classes, sensitive module touches, or novel dependency introductions trigger mandatory human review. Over time, correlate incident data with the AI flag to tune thresholds—given that half of workers already use unapproved AI, visibility on origin is your early warning system.
Many organizations benefit from AI maturity assessments. Which capability areas matter most for engineering teams, and how do you translate a score into a concrete 90-day roadmap? Please include example milestones and success metrics.
I assess along access governance, runtime controls, data safeguards, developer experience, and measurement. In 90 days, aim to: 1) consolidate access through a central layer with basic redaction, 2) pilot process-level egress controls for one agent, 3) tag AI-originated code in two top repos, and 4) publish weekly usage and policy reports. Success shows up as increased routed traffic versus personal keys, reduced policy denials over time as patterns stabilize, and cleaner audit trails ready for compliance. With over half of users already active weekly, these milestones convert unmanaged demand into governed practice without slowing delivery.
In the “migrate” phase, what are the fastest wins when moving to cloud-based, standardized dev workspaces? Detail the reference architecture, golden images, and identity boundaries that set the stage for governed AI.
Standardize on cloud dev environments with golden images that include approved IDEs, the AI routing plugin, and preconfigured network policies. Bind workspace identity to your SSO so every AI call carries an enterprise principal, not a personal token, and isolate per-project data volumes to prevent cross-tenant leakage. Route all outbound AI traffic through the access layer by default; developers still choose tools, but the path is governed. This foundation turns scattered, weekly shadow usage into observable, policy-enforced activity that security and engineering can both support.
In the “modernize” phase, how do you embed AI governance and auditing into everyday developer tools without adding friction? Share UI/UX tactics, policy-as-code patterns, and training approaches that stick.
Meet developers where they work: lightweight IDE toasts that explain redactions, pull request badges showing AI involvement, and one-click links to audit details. Express rules as policy-as-code in version control, with preview diffs so teams see impacts before rollout; align conditions to build/test/release stages rather than tool names so governance survives model swaps. Offer short, in-IDE micro-trainings tied to actual events—“why this was redacted” or “how to scope context safely”—instead of abstract courses. When the UI is transparent and the policy is legible, adoption happens organically, even among the half of users already experimenting weekly.
In the “multiply” phase, where do agentic workflows deliver the best ROI—testing, code refactoring, ops runbooks? Provide two case studies with baseline metrics, ramp-up timelines, and realized savings or defect reductions.
Testing and ops runbooks are sweet spots because inputs are structured and outcomes are verifiable. Case one: generate and maintain test scaffolds and fixtures from PRs—baseline metrics include test coverage and escaped defects; in weeks, teams see steadier coverage growth and fewer late-stage surprises once agents are governed through the central layer. Case two: ops runbooks for repetitive diagnostics—baseline on-call task duration and handoff latency; with allowlisted tooling and audit trails, handoffs become clearer and toil drops as playbooks are executed consistently. The ramp is quick because the guardrails—access routing, egress controls—are already in place from earlier phases.
Governance tied to specific tools can age quickly. How do you anchor controls to fundamental build/test/release processes instead? Walk through a control map that survives model swaps and supplier churn.
Anchor at lifecycle checkpoints, not vendors. In “build,” gate AI access through the central layer, log provenance, and tag AI-originated diffs; in “test,” enforce SAST, dependency scanning, and policy checks keyed to code risk; in “release,” require provenance attestations and change approval rules that consider AI flags. Swap models freely behind the routing tier—your policies refer to data sensitivity, repo criticality, and artifact types, not brand names. This way, even as tools churn and more than half of the workforce experiments weekly, your assurance story stays intact.
What KPIs should executives watch to balance speed and safety—e.g., cycle time, incident rate, leakage findings, model spend? How do you instrument these and set guardrails that auto-correct before issues escalate?
Track cycle time and change failure indicators alongside leakage findings from the AI proxy and policy-denial trends. Instrument via the central access layer, CI/CD metadata, and incident systems; publish weekly dashboards so leaders see usage, risk, and outcomes together. Set auto-guardrails: budget caps per workspace, policy throttle-on-denial spikes, and mandatory human review if AI flags and high-severity findings co-occur. With half of workers using unapproved AI, steering signals must be near-real-time so you can course-correct before small leaks become audit headaches.
Change management is often the hardest part. How do you win developer trust while enforcing guardrails? Share messaging, champions networks, and incentive structures that helped adoption.
Lead with enablement, not prohibition: “Use AI safely, here’s the path,” instead of “Don’t use AI.” Stand up a champions network across top repos, give them early access, and let them shape redaction and routing defaults. Share transparent metrics—how many times redaction protected data this week, how many policy denials converted to allows after tuning—so teams see value, not just control. Considering that more than half engage weekly, meeting them with better, safer defaults turns shadow usage into partnership.
For MSPs and channel partners, how do you package services across specification, implementation, and managed operations? Outline pricing models, SLAs, and a sample quarterly value report that resonates with engineering and security leaders.
Offer three bundles: 1) specification via maturity assessments and reference architectures; 2) implementation for access layers, IDE integration, and pipeline controls; 3) managed ops for policy updates, audit reporting, and incident response. Price by scope and usage tiers routed through the central gateway, with SLAs around uptime, policy-decision latency, and audit report delivery. A quarterly report should show routed-versus-unguarded traffic trends, policy actions taken, audit readiness status, and highlights from “migrate/modernize/multiply” progress. With half of workers already on unsanctioned tools, this framing shows how you’ve shifted risk into governed, observable lanes.
Vendor selection is critical. What must-have capabilities—governance, observability, policy enforcement—separate durable platforms from shiny tools? Tell a story where a feature you insisted on prevented a major issue.
Non-negotiables are: centralized routing with model-agnostic policy, process-level network controls, strong audit trails, and data-protection primitives like redaction and tokenization. I once required process-scoped egress allowlists; a team balked, then later a prompt tried to push an agent to “phone home” to an unknown domain. The allowlist blocked it, the audit trail captured the attempt, and the just-in-time credential model ensured no lateral movement—what could’ve been an exfiltration became a logged non-event. Durable platforms make that kind of quiet save routine.
What is your forecast for shadow AI in software development?
Shadow AI isn’t going away; it’s normalizing into everyday engineering in the same way shadow IT once did, only faster because the perceived benefits land immediately. With half of workers already using unapproved tools—and over 70% in the UK, with more than half engaging weekly—the curve is steep, so governance must be embedded, invisible, and process-centric. The winners will route access centrally, confine runtime behavior with process-level controls, and measure outcomes in the language of build/test/release, not tool logos. Do you have any advice for our readers? Start by embracing the reality of weekly grassroots usage, stand up a central access layer with redaction this month, and let data from your own workflows guide where to tighten or relax—governance that rides the flow will always beat governance that tries to dam it.
