Can Agentic Developer Platforms be deployed safely in a regulated sector?

Agentic Developer Platforms (ADPs) are the future. Accelerating infrastructure scalability without growing developer numbers. Commoditising models to further reduce costs. Delivering ownership of your infrastructure to strengthen IP and remove licensing agreements. But how can you deploy ADPs safely and securely in highly regulated environments?

It seems like platform engineering is here to stay. Around 90%(1) of organisations have adopted it through the building of internal developer platforms (IDPs) to cope with the growing twin challenges of rapid team expansion and complex cloud infrastructure, which have outpaced the ability of traditional, ad-hoc processes to scale. IDPs help to handle this complexity, offering self-service tools that allow developers to deploy code independently without getting bogged down in infrastructure.

However, technology innovation moves increasingly quickly, and the race to optimise AI in infrastructure development is already starting to render IDPs obsolete. Why? Because most were built under the assumption they will be handling human-paced development, simple workloads, and a single reviewer per change. Introducing AI breaks all those assumptions at once.

When code volume rises two to 10 times(1) when powered by AI, and agents start writing, reviewing and deploying, the bottleneck shifts from writing code to shipping it safely. A word of caution here: speed on its own is a mirage. AI makes a developer feel faster long before it makes the business ship faster, and closing the gap between the two is the platform's job, not the model's. IDPs are not up to this task, which is of particular concern for highly regulated sectors such as finance, the public sector and pharmaceuticals, which must comply with an array of regulations including UK GDPR, and the European Union AI Act and Digital Operational Resilience Act (DORA).

So, does AI make platforms less necessary? No, it makes them even more vital. Because it's the platform that decides whether AI's significant increase in coding speed is turned into business value or sheer chaos, plus how secure the process is. Yes, this demands a new type of platform. But those companies that have invested in an IDP don't need to start from scratch. They can solve the problem by adding a new AI layer to their IDP and turn it into an ADP.

Securing an ADP

ADPs don't only enable companies to optimise the impact and value of AI in infrastructure development, but also to do this safely and securely – if built in the right way. In regulatory industries, security and compliance hold a veto. Ensuring an ADP gets the green light at board level means building control into the platform, rather than bolting it onto each agent. That's because control is best enforced at the infrastructure layer, making it the platform's job. This means it's vital for every ADP to ensure all agent actions carry full attribution, from agent ID to prompt, model and timestamp, logged with an audit trail – essentially, exactly the evidence regulators demand. Control and accountability should stay with named identities.

This is particularly important at a time when roughly 70% of firms have an AI policy, but around 89% of platform engineers use AI daily**. This gap is where a regulated firm can get painfully exposed. Hallucinated infrastructure-as-code (IaC) that ships over-permissioned, identity and access management silently dropped, prompt injection in a pipeline are just three of the scenarios keeping CIOs awake at night. "The model did it" is not a defence a regulator accepts. It's vital for accountability to be structural. It should not be reported after the fact.

Key control features

Mindera's current work with a Fintech, transforming its IDP to an ADP, is an example of how control, security and compliance can be built into a platform. Key governance features deliver trust, control and safety, including:

GitOps-only writes Delivering a single source of truth, here the Git repository defines the declarative state of the platform. Automated reconciliation, where GitOps tools such as Flux CD or Argo CD actively monitor the repository and provision resources to match it, completely circumvents manual modifications. If someone changes a provisioned resource directly rather than through Git, configuration drift reversion means the tool detects it and immediately reverts the state to match the Git repository.

Key benefits are an immutable audit trail and enhanced security, as developers do not require direct production access or long-lived credentials, which minimises the attack surface. Plus, instant rollbacks make recovering from a bad deployment as simple as running a git revert.

Identity propagation This involves end-to-end preservation of a user's identity as a request travels across multiple services or microservices. By recognising the specific user's context (such as their ID or group) rather than a generic service account, systems can apply granular, attribute-based access control and maintain accurate audit trails.

This ensures the security journey of an individual user is tracked from the edge – like an API Gateway or a Business Intelligence (BI) tool – all the way down to the underlying data source.

Liability follows control There is a legal principle forming underneath all of this that it’s worth naming: Liability follows control. Whoever controls the system answers for what it does. Courts and regulators across major jurisdictions are converging on the same position: a defendant cannot plead that an AI acted on its own, and human oversight has to sit at the centre of any high-risk system.

Essentially, you cannot hand accountability to a model. In a regulated firm this stops being abstract and lands on a name – most accountability regimes require a named, senior individual to answer for the outcome, which means clearly defining who, or what, made this change.

That answer is the audit evidence the path itself produces. A chronological audit trail of actions and system events proves how a specific record, transaction, or control was processed from start to finish. This traceable chain of events establishes the 'who, what, when, where and why' of a transaction, validating that systems are secure, compliant and accountable.

It provides an immutable, chronological record of code changes and system events, ensuring that development paths are transparent, traceable, and protected against unauthorised access. In a regulated firm the audit trail is not a nice-to-have. It is the evidence that keeps a real, named person out of trouble.

Constraining agent behaviour Simply supervising behaviour with a human approving each agentic action is fallible. People approve around 93% of prompts(3), and attention erodes with volume. Oversight designed to add safety quietly removes it through approval fatigue. More capable models aren't safer, they're better at routing around restrictions no one wrote down.

The solution to this problem is to automatically constrain what an agent can reach through features like sandboxes, isolated execution, filesystem boundaries and egress controls. Start by constraining agents at the environment layer first, then steer them at the model layer. The deterministic always-on boundary, tailored to a user's oversight, then holds when probabilistic defences fail, ensuring safety no longer depends on a tired human clicking 'approve'.

That boundary is also what changes the human's job. Instead of sitting in the loop and signing off every diff, the person moves on to the loop – setting the limits, watching the signals and the evidence, and stepping in on the few decisions that genuinely need judgement. You can only make that move safely if the platform underneath can be trusted to catch what the human no longer inspects by hand.

The validation loop Constraining what an agent can reach is only half the answer. The other half is what happens when it hits the boundary. A crude platform lets the agent fail silently and burn cycles retrying blind. A validation loop instead returns structured, machine-readable feedback the agent can read and act on, so it corrects itself inside the governed boundaries rather than hammering at them.

The two controls only work as a pair, and this is the part teams miss. Privilege separation without a validation loop gives you agents that stall at every wall and waste resources on blocked actions. A validation loop without privilege separation gives you agents that simply get better at working around the rules. They have to be designed together, because the loop needs to know where the boundaries are to give useful feedback, and the boundaries need the loop to stay enforceable without killing velocity.

Model sovereignty and data residency For a regulated firm, the question is not only what an agent does. It is where the model runs and whose laws it sits under. Personal and regulated data often has to stay within an approved jurisdiction, and a model hosted in a foreign cloud brings concentration, outage and data-residency risk.

Regulators have increasingly flagged AI and cloud as potential critical dependencies. An ADP built for a regulated estate keeps data, compute and models under the firm's own control, self-hosting open-weight models on owned infrastructure where the sensitivity of the workload demands it. This is the ownership argument from the top of this article made concrete: your IP and your data stay inside your walls, and you are not renting your compliance posture from a vendor you cannot audit.

Continuous evaluation An agent in the delivery path is itself a model, and a regulated firm has to treat it like one. Supervisory expectations on model risk mean the models in your pipeline need identifying, validating and monitoring over time, not just guarding.

That makes evaluation a first-class part of the platform: automated evaluations that check the agent's output quality run continuously. Containment lets you show a regulator that you stopped the agent doing harm. Evaluation lets you show the other thing they ask for – that you validated it doing the right thing.

Governance by design

Whichever statement lands hardest with your board – output, governance, safety, cost, experience or architecture – the conversation ends in the same place: the platform, not the model. And for most large organisations, the platform rebuild you've already funded is where it gets proven. At Mindera we design and deliver ADPs for large and regulated enterprises on clean foundations, governed by design, owned by your own team, and vendor-neutral on models and clouds.

We meet organisations where their platform is, harden the foundations, and add the agent substrate as a layer, starting with low-risk paths, then hybrid validation loops as trust is earned. If no platform currently exists we design and build a safe, secure ADP from scratch.

That staging is the whole point. There are levels to agentic development, from a human approving every change up to paths that respond to signals on their own. The mistake regulated firms make is reaching for a high level on a platform that can only safely support a low one – Level 3 ambitions on a Level 1 substrate.

You earn each level with evidence. This is also how to reframe governance for a board that hears "controls" and thinks "brake pedal": Guardrails are not a permanent tax on speed. They are the thing that lets you safely hand more work to agents over time. The better the governance, the more autonomy you can extend.

Every regulated company now has access to the same models. The competitive edge belongs to whichever organisation builds the better, more secure and compliant platform around them.

Get in touch with our platform engineering team today to discuss turning your IDP into an ADP and other platform challenges…

Sources:

1. Platform Engineering 2.0: An evolution for the AI era — https://platformengineering.org/blog/introducing-platform-engineering-2-0-an-evolution-for-the-ai-era
2. State of Platform Engineering 2025 — https://weaveintelligence.io/research/state-of-ai-in-platform-engineering-2025
3. Anthropic, Claude Code auto mode — https://www.anthropic.com/engineering/claude-code-auto-mode