For a software company, introducing autonomous coding agents can start as a productivity experiment. For a bank it starts as an architecture, security and governance problem, because an AI system that reads repositories, executes commands, calls APIs, modifies code and opens Pull Requests is a new machine actor inside the Software Development Lifecycle.
A bank therefore has to decide what that actor may access, which models it may use, where data may travel, how credentials are protected, how its output is independently verified, when human approval is mandatory, and how every action can be reconstructed months later for security, compliance or audit purposes. None of these can be implemented inside a system prompt or delegated to the agent itself. They require controls that sit outside the model: identity and access management, network isolation, policy enforcement, workflow orchestration, independent quality gates and an audit layer.
Visdom is an AI-native SDLC platform built for regulated industries, where autonomous AI in software development has to coexist with strict requirements for security, governance, auditability and human oversight. It is built around those constraints at the architectural level: self-hosted deployment, controlled model access, isolated agent execution, explicit approval gates and a verifiable audit trail.
See how we can assist you: AI-Native SDLC for Banking
Coding agents run inside that environment rather than being replaced by it. Claude Code, Codex, IBM Bob or another agent performs the implementation work, while Visdom determines the context the agent receives, the boundaries it operates within, the validation its output must pass, and the evidence retained from the execution.
Want to know more about Visdom? Learn its architectural overview:
Download the whitepaper >1. A bank must control where its code and prompts go
Source code is no longer the only sensitive asset once AI joins the development process. Prompts carry business logic, architecture details, ticket descriptions, incident information and fragments of internal documentation. Agent executions produce telemetry describing repositories, systems and engineering activity. A bank needs to know exactly where all of it is processed and whether any of it leaves its infrastructure.
Visdom runs self-hosted inside the customer's Kubernetes environment. There is no vendor-operated control plane and no outbound telemetry to VirtusLab infrastructure. The deployment also supports air-gapped operation: platform images are delivered as signed packages into the bank's internal container registry, with no internet connectivity required.
Model access follows the same principle. Visdom uses a BYO-LLM architecture, meaning the agent never talks to a model provider directly — it goes through a driver layer and an LLM gateway that the bank controls. The bank can route to an approved external model through its own gateway, or run open-weight models entirely inside its own infrastructure. Model versions are pinned explicitly rather than resolving to "latest", and allowlists are enforced as policy: an execution that requests a model outside the approved list is blocked and recorded as an audit event.
Under DORA, this materially changes the third-party risk picture. A self-hosted platform with no vendor control plane reduces the ICT concentration exposure described in Articles 28–30 and simplifies the exit strategy the bank has to document for any critical ICT provider.
2. AI needs machine-enforced boundaries
Traditional developer governance assumes a human actor who understands organizational policy. An autonomous agent does not carry that assumption. It executes commands, modifies files and talks to external systems, and telling it in a system prompt to stay away from production or from credentials is not a security boundary. Security controls have to constrain the agent rather than depend on the agent remembering to obey them.
Visdom implements this at the execution layer. Agent workloads run as isolated Kubernetes Jobs. Network policy is default-deny, and outbound traffic is limited to explicitly approved destinations: Jira, Bitbucket, package registries and the bank's LLM gateway.
The platform also enforces guardrails around the change itself, configured per repository or per workflow: limits on the number and scope of modified files, protection of critical paths, restrictions on removing or renaming public interfaces without explicit authorization, and token and cost budgets.
3. The agent should not possess credentials
A coding agent needs credentials to reach repositories, APIs, package registries and models. A real API key sitting in the agent's environment can surface in model context, in generated code, in command output or in logs.
Visdom separates the ability to use a credential from the ability to see it. Secrets are fetched just in time from the bank's secret store, such as HashiCorp Vault, and the agent receives a placeholder rather than the real value. A transparent network proxy substitutes the actual credential at the moment the request leaves for an explicitly authorized destination, and rejects the request anywhere else.
The proxy protects the secret's value, not the privilege attached to it, so authorization is scoped per destination and evaluated per request. An agent allowed to reach Bitbucket cannot use that allowance to reach an arbitrary endpoint, and the scope of what it may do at each destination is part of the policy rather than a property of the token.
This also gives the bank a structural answer to shadow AI. Approved models are reached through the platform, so raw model-provider API keys never have to be distributed to developers or to agents.
4. Every AI action needs attribution
A Git commit tells you what changed and which account committed it. That is not enough once AI materially participates in implementation.
Suppose a Pull Request causes a production incident six months after it was merged. The bank needs to reconstruct which model produced the change and at which version, what prompt started the work, what context was supplied, which tools the agent invoked, which files it inspected and modified, which policies were active, and which human reviewed the result.
Visdom AI Tracing is the flight recorder for this. It records agent sessions, prompts, model calls, tool usage, file modifications and resulting commits. Each event is hashed with SHA-256 and chained to the previous one, so any later edit to a stored event breaks the chain, and the chain is signed with the organization's Ed25519 key.
Visdom also provides line-level AI attribution derived from Git history and tree-sitter parsing (tree-sitter builds a syntax tree of the file, so attribution follows code structure rather than raw line numbers). Attribution is authoritative at session and commit level. At line level it is a best-effort mapping that degrades under large refactors and reformatting, which is worth stating up front rather than discovering during a demo.
AI governance then stops being a declaration that AI was used according to policy, and becomes evidence of how it was actually used.
5. Audit records themselves must be trustworthy
Recording AI activity solves half the audit problem. The other half is whether the record can be trusted, and an audit log an administrator can silently rewrite has limited evidentiary value.
Because events are cryptographically chained, altering one breaks verification of everything after it. The resulting trail is verifiable offline using the organization's public key, without the auditor having to trust the running Visdom instance. The private key lives in the bank's HSM or KMS; Visdom requests signatures and never holds the key material, which is what makes the offline verification argument hold.
Signed events export into the bank's SIEM over Syslog, structured JSON, Splunk HEC or Elastic Bulk, each carrying its sequence number, previous hash, current hash and signature. Platform-side retention is configurable with a 12-month architectural minimum; statutory retention periods, which in banking run to years, are served by that export into the bank's own SIEM or WORM storage rather than by the platform database.
This addresses the ICT risk management and logging requirements in DORA Articles 8–10 directly, since the same mechanism produces both the operational log and the evidence that the log is intact.
6. Human-in-the-loop must be part of the architecture
Human oversight is usually described as a governance principle. In an AI-native SDLC it also has to be a technical primitive.
Visdom workflows contain explicit Approval nodes. Approval policy defines who may approve a step, how long that approval stays valid, and what happens on approval, rejection or expiry. Human involvement is not confined to the final Pull Request: an agent can pause mid-execution to ask for clarification, and operators can attach context to a running execution, cancel it, or restart the workflow with new instructions.
How much autonomy a change receives is a function of its risk class, and the classification is described in section 7. For changes classified LOW, the bank's policy may permit automatic merge once every deterministic gate has passed. For MEDIUM and above, human approval is enforced by the platform and cannot be configured away. Separation of duties is preserved in both cases, because the gates that clear a change are independent of the agent that produced it, and the approver is never the agent.
7. AI-generated code requires a different quality model
Generative AI reduces the cost of producing code far more than it reduces the cost of establishing that the code is correct, which moves the bottleneck to review. Agents that generate changes faster than engineers can read them produce a queue of Pull Requests, and adding more agents lengthens the queue.
Visdom scales validation through layered review. The early stages are deterministic and cheap: collect the diff and repository context, run linting and formatting, build the project, scan for secrets, run SAST and analyze dependencies. The change is then classified by risk, and only changes above the configured threshold go to the expensive AI-based deep review. For MEDIUM and above, Visdom runs separate review lenses for Security, Correctness and Test Quality, with Performance and Maintainability available as additional dimensions.
Findings carry confidence levels rather than presenting every AI observation as equally certain. The design target is precision rather than sensitivity, because review that produces noise gets ignored or switched off, and that failure mode gets worse exactly as the volume of machine-generated code rises.
8. Tests written by AI need independent verification
If the same model writes an implementation and then writes its tests, a green build shows that the model agrees with itself. The tests can encode the same wrong assumption as the code.
Visdom Testing adds validation that does not depend on example-based tests produced by the coding agent:
- Architecture tests enforce structural constraints — layer boundaries, forbidden dependencies, prohibited legacy APIs — as assertions that fail the build.
- Property-based testing states an invariant that must hold and checks it against large numbers of generated inputs, instead of the handful of cases a developer or an agent thought to write down.
- Mutation testing deliberately injects defects into the changed code and measures whether the suite catches them, which tests the tests rather than the implementation. Because it is expensive, the mutation budget is scoped to changed code and scaled by risk class.
- Contract testing verifies compatibility between services before deployment, so a change to a provider cannot silently break its consumers.
Visdom also computes a Test Oracle Reliability Score, which identifies tests whose failures do not reliably indicate a real defect. Tests below the reliability threshold are quarantined, so autonomous agents do not burn iterations trying to fix flaky ones.
The question a bank has to answer about an AI-generated change is not whether the tests passed, but how much independent evidence those tests provide that the change is correct.
9. Enterprise AI needs organizational context, not just repository access
An agent can search a repository without understanding the organization that produced it. In a large bank, the knowledge required to change software safely is scattered: a shared library affects dozens of consuming services, the person formally listed as a component owner is often not the engineer who maintains it, an odd-looking implementation exists because of an architectural decision made years earlier, and a recurring review comment encodes a convention nobody ever wrote down.
Visdom Context Fabric turns those signals into infrastructure agents can consume. It aggregates source code, Git history, infrastructure-as-code, Pull Request discussions, Jira and documentation such as Confluence, and compiles them into a reusable knowledge layer rather than handing the agent an unstructured document dump. It distinguishes five levels:
- L1, system context: services, dependencies, contracts, architectural boundaries.
- L2, code context: conventions, build configuration, linting rules, recurring review rules.
- L3, organizational context: actual module owners, experienced reviewers, escalation paths.
- L4, historical context: ADRs, Pull Request discussions, postmortems, earlier architectural decisions.
- L5, operational context: telemetry and incident history.
Alongside the AI-generated knowledge, Context Fabric maintains deterministic analytical structures over Git history, dependency graphs and Pull Request discussions, which yield module ownership, blast radius, expertise maps and change heatmaps by computation rather than by inference.
What a bank needs is not an agent that can find some code related to a ticket. It needs an agent that knows what else may break if that code changes, who understands the area, and which historical constraints should shape the implementation.
In an estate of several thousand repositories this is also an infrastructure problem. Context Fabric indexes incrementally and prioritizes active repositories, so processing cost is proportional to change rather than to the size of the estate.
10. AI costs need governance too
With an IDE copilot, model spend stays tied to individual human actions. With autonomous workflows, one ticket can trigger multiple agents, several model calls, review iterations, test-generation cycles and retries, none of which a person approved individually.
Visdom records the model, token count, latency, status and cost of every call, and attributes cost to sessions, authors, Pull Requests, repositories, teams and whole workflows. Budgets are executable: an exhausted quota prevents the next workflow from starting, rather than showing up as an overspend at the end of the month. That difference matters as an organization moves from dozens of developers experimenting with assistants to hundreds or thousands of autonomous executions.
From AI coding to AI-native SDLC
A coding agent answers one question: can AI implement this change? A bank running an AI-native SDLC has to answer the rest of them, and each one is a decision the platform makes rather than a capability the model has:
- Should an agent be allowed to perform this task at all, and with how much autonomy for this class of change?
- What organizational context does it receive?
- Which repositories, APIs and network destinations can it reach?
- Which model and model version may it use, and where are code and prompts processed?
- How are credentials protected from the agent itself?
- What happens when the agent fails, stalls or exhausts its budget?
- How is the generated code independently validated, and which changes require human approval?
- How much is autonomous execution allowed to cost?
- How do we reconstruct what happened six months later, and prove the evidence has not been manipulated?
Coding agents remain replaceable execution engines inside the platform. Around them, Visdom supplies the organizational context, workflow orchestration, execution isolation, security policy, independent validation, human approval, observability and cryptographically verifiable audit trail that autonomous software engineering needs in a controlled enterprise environment.
Becoming AI-native therefore does not mean giving every developer a more powerful coding assistant. It means building an environment in which AI can take responsibility for larger parts of the engineering process: enough autonomy to change the speed and economics of software delivery, with enough context, verification and control to make that autonomy usable in a regulated institution.
Have any questions about AI-native SDLC or Visdom itself? Don't hesitate to contact us.