Key TakeawaysPublished evidence on AI coding productivity is genuinely mixed — from a 55.8% speed-up on a greenfield task to a 19% slowdown for experienced developers in mature codebases — so an enterprise rollout must measure its own outcomes rather than assume a gain.Agentic tools differ from autocomplete because they act: they read files, run commands, and call external systems, which makes permissions, not prompts, the primary control surface.Central to our model are centrally managed deny rules, deterministic hooks for policy that must always apply, reviewed skills for repeatable workflows, and an allowlist of approved tool integrations.AI-generated code has to go through the exact same review, testing, and security processes as human-written code; we see that developers who use assistants tend to produce less secure code, which they are also more confident in. Scale enablement for hundreds of engineers is a platform issue -- curate workflows, share guardrails, and improve the feedback loop, not a series of tool demos.Executive SummaryAgentic coding assistants can change files, execute shell commands, and use tools for engineers. That makes them useful for removing tedious work from engineering processes, but it also creates serious adoption challenges inside a regulated enterprise. Based on experience leading agentic AI automation programs and supporting more than 600 engineers at a large financial-services organization, this article describes an enablement architecture built on four layers: governance, guardrails, curated knowledge, and integration. It connects each layer to specific configuration choices, explains why existing software delivery controls must remain the final checkpoint, examines how to assess results when research points in different directions, and acknowledges where the approach falls short.IntroductionAdoption of AI assistance is now the norm rather than the exception. DORA's 2025 research reports that about 90% of surveyed technology professionals use AI, while 30% have little or no trust in the code it produces [11]. The 2025 Stack Overflow survey found 84% of developers using or planning to use AI tools, but only 14.1% using AI agents daily [22].That gap — broad use of assistants, cautious use of agents — is where most enterprises sit. Moving from suggestion to action changes the risk profile. An autocomplete suggestion is inert until a human accepts it; an agent can run a migration script, push a branch, or call an internal API. In a bank, that difference matters to security, audit, and model-risk teams.Engineers have at their disposal a powerful tool with default settings; also, each team develops its own prompts, and governance comes in late to impose restrictions, which in turn erode trust. As an alternative, we see here that what is put forth is to treat agentic AI as an internal platform with its own architecture.BackgroundAn agent, in the sense used by Anthropic's engineering guidance, is a system in which the model directs its own process and tool use, as opposed to a workflow that follows a fixed code path; that guidance also recommends starting with the simplest solution that works [7]. Coding agents connect to external systems through the Model Context Protocol (MCP), an open JSON-RPC-based protocol in which servers expose tools, resources, and prompts. The specification is explicit that tools represent arbitrary code execution and that hosts should obtain user consent before invoking them, while noting the protocol cannot enforce this on its own [6].Engineers in this environment use several assistants, including GitHub Copilot, Windsurf, Codex, and Claude Code. The examples below use Claude Code's configuration model because it documents the relevant controls clearly [1]–[5]; the architecture depends on the control types, not the product:Control typeQuestion it answersTypical mechanismCentral policyWhat is never allowed?Organization-managed settings, deny rulesDeterministic checksWhat must always be verified?Pre- and post-action hooksPackaged know-howHow should this task be done?Reviewed instruction files or skillsTool reachWhat can the agent touch?Allowlisted tool and MCP integrationsProblem AnalysisFour problems dominate in a regulated environment:Excessive agency. OWASP lists excessive agency — too much functionality, permission, or autonomy — among the top risks for LLM applications, alongside prompt injection [15]. A coding agent with shell access and broad credentials fits that description by default.Insecure output with high confidence. In a controlled study, participants with an AI assistant wrote significantly less secure code yet were more likely to believe it was secure [14]. An earlier evaluation found about 40% of generated programs in security-relevant scenarios contained vulnerabilities [13].Uncertain productivity. A randomized trial found developers completed a greenfield JavaScript task 55.8% faster with an assistant [8], whereas a 2025 randomized trial with experienced open-source maintainers on their own repositories found AI access increased completion time by 19% — even though participants believed it had sped them up [9].Regulatory ambiguity. U.S. banking model-risk guidance was revised in April 2026 (SR 26-2) and explicitly places generative and agentic AI models outside its scope, leaving firms to apply their own risk-management practices [21]. Frameworks that include the NIST AI RMF and its Generative AI Profile present that structure, but not tool-level configuration [17], [18].Architecture and DesignThe enablement architecture has four layers that are owned by different groups and which answer different questions (Figure 2). 1. Governance — what is never allowed. Central administration rules take priority over user or project rules [2]. The permit method is deny-first, involving the non-allowance of any rule that competes against a denial [1]. This level contains non-negotiable rules: it is forbidden to read the credentials file, to go into bypass mode, and push approval is required.2. Guardrails — what must always be checked. Hooks run deterministically at lifecycle events such as before a tool call [3]. The tool's own documentation recommends hooks, not instructions, for rules that must always hold [4]. Guardrails cover secret detection, blocked commands, and audit logging.3. Curated knowledge — how work should be done. Skills package a repeatable workflow — a migration recipe, a test-scaffolding procedure, a release checklist — as a reviewed instruction file loaded only when relevant [4]. This is where institutional knowledge lives.4. Integration — what the agent can reach. MCP servers connect agents to internal systems. Organizations can push an approved set and enforce allowlists [5], keeping integrations to the minimum OWASP recommends [15].Beneath all four sits the existing delivery pipeline: pull-request review, CI tests, and security scanning. Agents never get a separate path to production.ImplementationThe governance layer is a managed settings file distributed by the platform team:{ "permissions": { "deny": [ "Read(./.env)", "Read(./**/secrets/**)", "Bash(curl:*)" ], "ask": [ "Bash(git push:*)" ], "disableBypassPermissionsMode": "disable" }}Credential files are unreadable regardless of what a user or repository configures, arbitrary outbound HTTP from the shell is denied, and pushes require explicit human approval. Disabling bypass mode removes the option to skip prompts entirely.Guardrails are registered as hooks and implemented as small, testable scripts:{ "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "/opt/ai-guard/check-command.sh" }] }] }}#!/usr/bin/env bash# Receives the pending tool call as JSON on stdin.cmd=$(jq -r '.tool_input.command // ""')if grep -Eq '(prod|PROD)[-_]?(db|DB)|DROP[[:space:]]+TABLE'