Scaling Agentic AI Coding Assistants in a Regulated Enterprise

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 Summary

Agentic 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.

Introduction

Adoption 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.

Background

An 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 type

Question it answers

Typical mechanism

Central policy

What is never allowed?

Organization-managed settings, deny rules

Deterministic checks

What must always be verified?

Pre- and post-action hooks

Packaged know-how

How should this task be done?

Reviewed instruction files or skills

Tool reach

What can the agent touch?

Allowlisted tool and MCP integrations

Problem Analysis

Four 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].Figure 1: Published evidence on AI-assisted development is mixed. Left: change in task completion time in two randomized trials. Right: DORA 2024 estimated effect of a 25% increase in AI adoption on delivery and quality measures. Data from [8], [9], [10].
Architecture and Design

The enablement architecture has four layers that are owned by different groups and which answer different questions (Figure 2). 

Figure 2: Layered enablement architecture for agentic coding assistants. Central governance and deterministic guardrails constrain what agents may do; curated skills and approved integrations shape what they do well; existing delivery controls remain the final gate.

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.

Implementation

The 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’ <<<“$cmd”; then
  echo “Blocked by policy: production data or destructive SQL.” >&2
  exit 2   # exit code 2 blocks the call and returns the reason to the agent
fi
exit 0

The script inspects the pending command before execution and blocks patterns that policy forbids. Pattern matching is a last line of defense rather than a restrictive environment, but what we do in hooks is we treat them as any other function which we can test and which we put into version control a key feature which auditors will look at as they want to know how rules are put into practice. Also the hook is a very convenient place to put each command, which we then add to the main audit log.

A curated skill turns a recurring manual task into a reviewed procedure:

—
name: add-contract-test
description: Add a consumer contract test for a REST endpoint
  using the team’s standard template and naming rules.
—
1. Locate the endpoint’s OpenAPI definition.
2. Generate the test from templates/contract-test.java.
3. Run the module’s test target; do not modify production code.
4. Summarize the new test and any gaps in the PR description.

Skills are stored in a shared repository, reviewed like code, and versioned so improvements reach every team.

Enablement as a Progression

Configuration by itself will not change the way hundreds of engineers work. A scalable rollout takes them through three stages: first, they learn what agents can and cannot do, along with the relevant controls; next, they run curated skills against real tasks from their own teams; finally, they write new skills and submit them for review. The third stage is what turns a central program into a self-sustaining one, because the people closest to a manual workflow are the ones best placed to automate it.

Measuring Outcomes

Because self-reported gains are unreliable [9], measurement should compare cohorts rather than ask for opinions alone. Track, for adopting and not-yet-adopting teams over the same period: lead time and change-failure rate [11], review rework on AI-assisted pull requests, satisfaction and flow from periodic surveys [12], and guardrail block rates. A gain in speed that coincides with a rise in change-failure rate is not a gain.

Performance and Scalability

“Performance” here means organizational throughput and cost. Token spend grows with context size, so skills that load only on demand are cheaper than large always-on instruction files [4]. Hooks run synchronously in the agent’s loop, so guardrail scripts must be fast and fail closed; a slow or flaky hook is felt by every engineer on every tool call. Measure what matters using a multi-dimensional framework such as SPACE, which warns against relying on activity metrics alone [12]. DORA’s 2024 data found that higher AI adoption was associated with better documentation and code-review speed but slightly lower delivery throughput and stability [10]; track change-failure rate alongside any productivity measure.

Security Considerations

Treat the agent as a new principal with the developer’s privileges. Apply least privilege to credentials it can reach, keep production access out of developer sessions, and require human approval for high-impact actions, as OWASP recommends [15]. Treat content from untrusted MCP servers, issue trackers, and web pages as potential prompt injection [6], [15]. Map controls to the NIST Secure Software Development Framework and its generative AI profile so AI-generated code inherits established practices [19], [20].

A Failure Scenario: Injected Instructions

Consider an illustrative attack. An engineer asks an agent to fix a bug described in a ticket. The ticket text, written by someone else, contains a hidden instruction to read the repository’s .env file and send it to an external URL. The model may follow it — prompt injection is the top-ranked LLM risk for exactly this reason [15]. In the layered design, the read is denied by managed policy, the outbound curl is denied, an unapproved MCP server is not reachable, and any push requires human approval. No single layer has to be perfect; the attack must defeat all of them.

Operational Excellence

Log every tool call through hooks into a central store so that “what did the agent run?” is answerable for any session. Monitor guardrail block rates by rule: a rule that never fires may be unnecessary, while one that fires constantly may indicate a missing skill or a confusing workflow. Version-manage settings and roll them out progressively, as with any configuration change.

Trade-offs and Limitations

Centralized control makes experimentation slower, while no deny list can cover every case. A determined user can get around regex-based hooks, so they provide a last line of defense—not a sandbox. Curated skills also need regular maintenance; once they go stale, outdated practices can spread quickly. Measurement remains difficult because self-reported improvements are unreliable, as the 2025 trial showed [9]. For small teams with no regulatory obligations, the architecture adds more weight than they need.

Production Lessons Learned

Lesson: Start with workflows, not the tool. Agentic AI earns its place by automating well-defined manual engineering workflows end to end. Demonstrating the tool in the abstract builds curiosity; automating a team’s own recurring task is what gives it a reason to change how it works.

Lesson: Enablement scales through people. Mentoring more than 600 engineers was only possible through repeatable sessions, shared examples, and engineers who became local experts for their teams.

Lesson: Put rules in code, not in prompts. Instructions in a prompt or skill are guidance; anything that must always hold belongs in managed settings or hooks.

Lesson: Keep one path to production. The strongest argument for adoption with risk partners was that agents changed nothing about how code is reviewed, tested, and released.

Best PracticesDefine governance centrally; never rely on per-user configuration for security rules.Enforce invariants using deterministic hooks and put them to the test.Bundle recurring tasks up into proven, versioned skills.Whitelist integrations, that is to say, go through each external tool like it is code. Use many dimensions for measurement, which include stability in addition to speed. Future Outlook

Agent functions are shifting from single repository changes to multi-step, multi-system workflows; therefore, integration governance, which includes which tools, which credentials, and what approvals will break or make the value of the agent. OWASP’s agentic security work and successive LLM Top 10 editions are converging on a shared threat vocabulary [16]. Expect that regulators and internal risk teams will ask for proof of control efficacy, which in turn will favor those models in which policy is built into the code base and in every single action is recorded. 

Conclusion

Widespread integration of agent AI at an engineering scale is less a technical model issue and more a platform and policy implementation issue. A tiered architecture of governance, guardrails, curated data, and integration also provides an enterprise the ability to provide engineers with large-scale automation, which still leaves the risk partners with their confidence. The research does not promise a universal speed-up, so the most important design choice may be the commitment to measure honestly and adjust.

References

[1] Anthropic, “Configure permissions,” Claude Code Docs, 2026. [Online]. Available: https://code.claude.com/docs/en/permissions. Accessed: Oct. 5, 2026.

[2] Anthropic, “Deploy managed settings,” Claude Code Docs, 2026. [Online]. Available: https://code.claude.com/docs/en/managed-settings. Accessed: Oct. 5, 2026.

[3] Anthropic, “Hooks reference,” Claude Code Docs, 2026. [Online]. Available: https://code.claude.com/docs/en/hooks. Accessed: Oct. 5, 2026.

[4] Anthropic, “Extend Claude with skills,” Claude Code Docs, 2026. [Online]. Available: https://code.claude.com/docs/en/skills. Accessed: Oct. 5, 2026.

[5] Anthropic, “Connect Claude Code to tools via MCP,” Claude Code Docs, 2026. [Online]. Available: https://code.claude.com/docs/en/mcp. Accessed: Oct. 5, 2026.

[6] Model Context Protocol, “Specification (Version 2026-07-28),” 2026. [Online]. Available: https://modelcontextprotocol.io/specification/2026-07-28. Accessed: Oct. 5, 2026.

[7] E. Schluntz and B. Zhang, “Building effective agents,” Anthropic Engineering, Dec. 19, 2024. [Online]. Available: https://www.anthropic.com/engineering/building-effective-agents. Accessed: Oct. 5, 2026.

[8] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv:2302.06590, Feb. 2023. [Online]. Available: https://arxiv.org/abs/2302.06590

[9] J. Becker, N. Rush, E. Barnes, and D. Rein, “Measuring the impact of early-2025 AI on experienced open-source developer productivity,” arXiv:2507.09089, Jul. 2025. [Online]. Available: https://arxiv.org/abs/2507.09089

[10] N. Harvey and D. DeBellis, “Announcing the 2024 DORA report,” Google Cloud Blog, Oct. 22, 2024. [Online]. Available: https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report. Accessed: Oct. 5, 2026.

[11] N. Harvey and D. DeBellis, “Announcing the 2025 DORA report: State of AI-assisted software development,” Google Cloud Blog, Sep. 23, 2025. [Online]. Available: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report. Accessed: Oct. 5, 2026.

[12] N. Forsgren, M.-A. Storey, C. Maddila, T. Zimmermann, B. Houck, and J. Butler, “The SPACE of developer productivity,” ACM Queue, vol. 19, no. 1, pp. 20–48, 2021, doi: 10.1145/3454122.3454124. [Online]. Available: https://queue.acm.org/detail.cfm?id=3454124

[13] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions,” in Proc. 2022 IEEE Symp. Security and Privacy (SP), San Francisco, CA, USA, 2022, pp. 754–768, doi: 10.1109/SP46214.2022.9833571. [Online]. Available: https://arxiv.org/abs/2108.09293

[14] N. Perry, M. Srivastava, D. Kumar, and D. Boneh, “Do users write more insecure code with AI assistants?,” in Proc. 2023 ACM SIGSAC Conf. Computer and Communications Security (CCS ’23), Copenhagen, Denmark, 2023, pp. 2785–2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622

[15] OWASP Gen AI Security Project, “OWASP Top 10 for LLM Applications 2025,” 2024. [Online]. Available: https://genai.owasp.org/llm-top-10/. Accessed: Oct. 5, 2026.

[16] OWASP Gen AI Security Project, Agentic Security Initiative, “Agentic AI – Threats and mitigations,” v1.0, Feb. 17, 2025. [Online]. Available: https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/. Accessed: Oct. 5, 2026.

[17] National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” NIST AI 100-1, Jan. 2023, doi: 10.6028/NIST.AI.100-1. [Online]. Available: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[18] C. Autio et al., “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1, Jul. 2024, doi: 10.6028/NIST.AI.600-1. [Online]. Available: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[19] M. Souppaya, K. Scarfone, and D. Dodson, “Secure Software Development Framework (SSDF) Version 1.1,” NIST SP 800-218, Feb. 2022, doi: 10.6028/NIST.SP.800-218. [Online]. Available: https://csrc.nist.gov/pubs/sp/800/218/final

[20] H. Booth, M. Souppaya, A. Vassilev, M. Ogata, M. Stanley, and K. Scarfone, “Secure software development practices for generative AI and dual-use foundation models: An SSDF community profile,” NIST SP 800-218A, Jul. 2024, doi: 10.6028/NIST.SP.800-218A. [Online]. Available: https://csrc.nist.gov/pubs/sp/800/218/a/final

[21] Board of Governors of the Federal Reserve System, OCC, and FDIC, “Revised guidance on model risk management,” SR 26-2, Apr. 17, 2026. [Online]. Available: https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm. Accessed: Oct. 5, 2026.

[22] Stack Overflow, “AI,” in 2025 Stack Overflow Developer Survey, 2025. [Online]. Available: https://survey.stackoverflow.co/2025/ai. Accessed: Oct. 5, 2026.

About the Author

Lokesh Suri is a Senior Vice President and engineering head at a global financial services company which he has been with for 20 years during which he built out enterprise systems in Java and Python in investment banking, retail banking, anti-money laundering, and regulatory risk. He is at the forefront of agentic AI automation projects and also runs mentorship programs in which he has worked with over 600 engineers in AI-assisted engineering practices, and also does regular training for new engineering hires on continuous delivery. He has also obtained AWS Cloud Practitioner and AWS Architect certifications.