How financial institutions can operationalize AI-DLC quickly and effectively

Financial institutions are adopting AI coding agents at pace, but most lack a governance framework that satisfies regulators or their own risk appetite. The result is powerful tools generating code outside institutional control. In our earlier post AI-Driven Development Lifecycle for Financial Services (AI-DLC) we explained how our customers are operationalizing this.  Now we go deeper: how do you configure the governance layer that makes an agent operate within your institution’s rules, regardless of whether your teams use Kiro from Amazon, Anthropic Claude Code, or OpenAI Codex? In this post, you will learn how to build a governance harness in days, and what engineering and Governance, Risk and Control (GRC) teams gain from it.

The governance layer of the harness

Why does this matter?

Without a governance layer, a coding agent becomes a powerful but uncontrolled actor. Generated code may violate data handling or conduct rules. Unapproved dependencies increase likelihood of an issue. Secrets can be inadvertently disclosed through vulnerable packages. Regulators find no evidence of oversight. The governance layer converts organizational policy into technical constraint, verifying speed-to-code does not come at the expense of control.

Each major coding agent (harness) provides the primitives to build the Governance Layer:

These files encode the company’s specific standards. The harness is built for the company, from the company’s existing knowledge (policies, architecture design guidelines, security standards, etc.) e.g. by directing the coding agents to read the design guidelines and extract the relevant information to be encoded in skills, hooks, steering files and agents.

What the governance layer of the harness delivers:

1. For engineering leadership: Consistent, governed output from every developer and every agent interaction. New joiners inherit the full rule set on day one by cloning the repository.
2. For GRC team: Data points to build the compliance surface that automatically translates engineering evidence into regulatory-ready reporting.
3. For delivery teams: The speed of agentic development without the rework of ungoverned code. The agent asks before it deviates and the institutional knowledge compounds as the team learns.

What we built in 3 days with an FSI customer

We recently ran an engagement with a large European insurance company that needed to apply new UI guidelines across existing interfaces using agentic development, while maintaining conformance to institutional rules. Following the AI-DLC Inception phase, the customer’s engineers, working with AWS, built the governance layer of the harness and built the skills necessary to maintain it in three days. The customer chose Kiro for its native steering-file architecture and spec-driven development workflow.

The Governance Layer we built has six components, each mapping to a risk control familiar to the compliance and risk team:

During the engagement, senior engineers and architects prompted Kiro to generate harness components from guidelines documents, code examples, and institutional knowledge held by the team. The workflow was iterative: the team reviewed the initial harness to remove obvious errors, provided predefined inputs, steered the agent when needed, and applied corrections to the harness whenever the output fell short of expectations. This process surfaced a practical question: given the multiple improvement levers available, what is the most efficient way to refine the harness? The rules for building the harness are still emerging and lack tight formalization; moreover, they evolve with each new model release. This makes an experienced practitioner essential to guide the team as the harness is refined and adapted over time.

What each component delivers in governance terms

Step 1: Define the rules (persistent context)

The agent operates within documented, version-controlled policy. Every rule has a single owner (a human) and traces to an institutional standard.

Existing guidelines are converted into each agent’s native instruction format: Kiro steering files, Claude Code’s CLAUDE.md, or Codex’s AGENTS.md.

Key design principles (agent-agnostic):

1. Scope rules to relevant context: frontend standards load only for frontend tasks, preventing context dilution so the agent sees only relevant rules.
2. Requirement-level vocabulary (MUST / MUST NOT / SHOULD / MAY): RFC 2119 constraint keywords to ensure deterministic AI agent behavior. These keywords are written in upper case giving them a heavier weight and ensuring better adhesion by the agents.
3. Mandatory questioning discipline: before generating code from ambiguous requirements, the agent gathers answers to mandatory questions. For institutions where a misunderstood requirement becomes a customer-facing error, this is high-value governance.

Step 2: Enforce deterministic controls (automated gates: hooks)

Controls that can be checked deterministically are scripted by the coding agent with human review to remove the possibility of human error or AI hallucination and provide reproducible evidence for auditors.

Persistent context drives the agent’s behavior; automated gates enforce it deterministically:

1. Compliance on save: every File-Save triggers policy checks, routing violations back to the agent for immediate correction.
2. Verify-before-done: the agent cannot declare a task complete without evidencing compilation, test, and lint output.
3. Pre-execution blocks: dangerous operations require human-in-the-loop approval before running.

These extend into the CI/CD pipeline as a second level of defense.

Step 3: Package procedures as skills (procedural governance)

Complex multi-step workflows that previously were executed in different ways depending on the proficiency of the developer, and therefore could cause deviations and errors, can now be executed the same way every time regardless of which developer or which session invokes them, encoding the institutional procedures and producing compliant outputs.

Persistent context tells the agent what to do; skills tell it how. A skill is a versioned directory (anchored by SKILL.md) packaging instructions, templates, and scripts into a repeatable workflow. The agent discovers skills by name, loads full instructions only when relevant, and follows the same procedure every time.

1. In Kiro: SKILL.md files in .kiro/skills/, discoverable by keyword matching
2. In Claude Code: skill folders in .claude/skills/, each with a SKILL.md and optional scripts
3. In Codex: skill folders in .agents/skills/ at repo, user, or system scope; distributable via plugins

Skills bridge guidance and enforcement: they encode procedures that produce compliant output, reducing how often hooks fire. Because skills live in the repository, every change is tracked in git. Skills follow the open agent skills standard (agentskills.io), protecting investment as tooling evolves.

Step 4: Compound institutional knowledge (the knowledge loop)

The company’s standards and institutional knowledge improve continuously. Every new rule links back to dated corrections in git history (traceability).

Code corrections are captured as a timestamped, tagged episode in a version-controlled file. When a pattern recurs three times, it is promoted to a permanent rule, compounding institutional knowledge reviewed and approved by a human.

In practice, a recurring correction becomes a new steering-file entry (Kiro), rule file (Claude Code), or AGENTS.md update (Codex). When a rule can be checked deterministically, script it.

Step 5: Maker-checker for agents (oppositional review)

High-risk changes receive independent and isolated-context review before a human ever sees them. This is the same segregation of duties that risk functions require for sensitive operations.

The coding agent generates code, then a reviewer agent with an isolated context critiques the output against steering rules. They loop until approval or escalate to a human. Companies apply this selectively to high-risk changes where the cost of a missed defect exceeds the review cost.

Step 6: Scope agent capabilities (permission boundaries)

Agent autonomy is central to the speed gains of agentic development, and the previous components already constrain what the agent should do. Permission boundaries add a final safeguard: they ensure the agent cannot reach beyond what the task requires when solving a problem. We configure least-privilege access so the agent cannot read, modify, or execute anything outside its defined scope.

1. In Kiro: custom agent definitions declare which tool categories (read, write, shell) the agent receives.
2. In Claude Code: a four-layer permission system (mode, allow/deny/ask rules, hooks, OS-level sandboxing) evaluates every tool call through a fail-closed pipeline.
3. In Codex: approval policy and sandbox mode provide configurable human sign-off and OS-level isolation.

Unlike humans, agents never tire of reporting. Where manual evidence collection is tedious and error-prone, an agent treats every compliance check as just another task, executed with the same rigor whether it is the first or the thousandth. Part of the harness can therefore be organized around continuously collecting the evidence auditors may request, storing artifacts in a structured repository that makes producing an audit report a retrieval exercise rather than a reconstruction effort.

The governance layer of the harness delivery pipeline

How do you validate the harness performs its governance function? As a software artifact, it gets its own delivery pipeline with two validation layers:

Layer 1, static validation (every code change, in seconds): automated checks verify no broken links, proper formatting, rule ownership, and working scripts. This confirms the governance artifact is correctly assembled before it runs.

Layer 2, behavioral regression (nightly and on every model change): the agent runs against known scenarios with predetermined correct outputs to verify rules work at runtime. Layer 1 asks \u201care the rules set up right?\u201d; Layer 2 asks \u201cdo they work when the AI runs?\u201d

The key insight: harnesses need ongoing calibration

Our experience working with customers has proven that governance harnesses work, but require monitoring, calibration, and joint ownership by engineering and GRC teams to be successful.

Models evolve, and harnesses must evolve with them. Practical guidelines:

1. Keep hard approval gates only for genuinely irreversible actions: new dependencies, structural refactors, scope-changing decisions.
2. State each rule once, in one place, with a single owner.
3. Scope rules conditionally by domain and file type.
4. Eliminate contradictions and dangling references first: a clean, conflict-free rule set is the single largest quality lever.

The underlying principle is familiar: over-control degrades the process it protects, and inconsistent policy is worse than sparse policy. The calibration point moves with every model generation, which is why the harness needs regression testing. This calibration discipline is a skillset GRC functions must develop to capture agentic AI benefits within defined risk appetite.

Harnesses don’t work alone

This framework assumes mature DevSecOps practices are already in place: automated CI/CD, branch protection, and code review culture. Start there before layering agent governance on top.

Critically, steering files and prompt-based rules are non-deterministic controls: they influence agent behavior but cannot guarantee it. Full governance requires supplementing these with deterministic controls in the CI/CD pipeline (linters, static analysis, policy-as-code gates) that enforce compliance regardless of what the agent produces. The harness works best as a layered system: non-deterministic controls reduce violations at generation time; deterministic controls catch whatever slips through before code reaches production.

Conclusion

The governance gap we opened with is solvable, and solvable quickly. AI-DLC gives financial institutions the methodology; the governance harness gives them the tools to operate agentic development at scale with compliance built in. The harness makes the implementation of compliant code easier while logging more systematically the decisions taken during this implementation. The logs create visibility and transparency that can be turned into regulatory evidence without extra efforts from the development teams.

The prerequisites are executive alignment and mature DevSecOps practices for the harness to amplify. The investment is smaller than most institutions expect: the foundational harness takes shape in days because it is built from knowledge the institution already has, not net-new policy work.

Contact your AWS account team to learn more about how AWS can help you build an effective governance layer as a part of your AI-DLC deployment harness.

Further Reading

1. AWS Blog: AI-Driven Development Life Cycle (Methodology Introduction)
2. AWS Blog: Open-Sourcing Adaptive Workflows for AI-DLC
3. Kiro Steering documentation, Kiro Hooks documentation, Kiro CLI v3 documentation
4. Claude Code: CLAUDE.md and Rules documentation, Hooks, Subagents
5. OpenAI Codex: AGENTS.md documentation, Config profiles, Sandbox modes
6. Kiro Changelog