From AI development to AI governance with AIDLC

Too often, AI agent controls get added after go-live, once the agent already has a key and a job. Build governance into how agents get made instead. That means a registration record before the first credential, checks in the pipeline, an identity tied to where the agent runs and evidence your auditor can read. This is part 3 of our agent governance series, and it starts before the agent exists.

If you're new to the series, start with part 1, on owning and governing your AI agents and part 2, on kill switches and runtime control. For one agent's own login and per-task tokens, see our post on agents as privileged users. This part is for teams who'd rather new agents arrive governed than clean up after them.

Many companies govern agents in the order they find them. An agent turns up in a discovery scan, someone hunts for its owner, and then its access gets trimmed. Parts 1 and 2 cover that work, and you'll always need some of it. It's slow, though, because every fix lands on something that's already running and that somebody relies on.

NIST's AI Risk Management Framework wants risk managed continuously, all the way through an AI system's life, and it treats governance as something that runs through every other function. NIST's Secure Software Development Framework says much the same about software. Few lifecycle models deal with security in detail, so you bolt the practices onto whatever model you use. For agents, that's the AIDLC. Fix a gap once in the pipeline and every agent built after it gets the fix for free.

For engineers, the useful shift is treating the agent's registration as an input to the build. Once the purpose, tool list and scopes sit in a file next to the code, the pipeline can diff them, test them and refuse a release that doesn't match. None of the technology is new. Signing, provenance, policy engines and workload identity already run for ordinary services in many shops. The AIDLC just points them at agents.

We use AIDLC to mean the AI agent development lifecycle, the stages an agent goes through from the first idea to the day it's switched off. Our six stages are intake and design, build, test and evaluate, deploy, operate and retire. NIST and ISO don't define the term. It's a working map, and each framework in this post lines up against it.

Still, this isn't a normal app. NIST's SSDF profile for generative AI points out that code and data blur together, and that model weights can be tampered with. A crafted query can even become an injection attack. Then there's what's new here: the software chooses its own tools, which turns permissions into a design question. Early on is when they're easiest to get wrong.

This is the map we'd start from. Each stage answers one governance question with a control. The control leaves something behind you can show later, and the last column names the framework that asks for it. That way the same work counts toward an audit.

Two rows do most of the work. Intake decides what the agent is allowed to be, and deploy refuses anything that doesn't match. The stages in between produce the proof that it matches. If you only have budget for two gates this year, put them there.

The registration record is the cheapest control in this post. Someone fills it in before the agent gets a credential, and later the pipeline checks every build against it. NIST's AI RMF wants intended purposes documented and an inventory of AI systems. With the template, nobody can skip either one.

Microsoft Entra has a version of this built in. Its docs call an agent identity blueprint a template for creating agent identities, and it holds how they're created and authenticated. Keep your own template anyway. The blueprint covers how agents sign in and what they're allowed to do, and your review still needs the purpose, the data and a way out.

# filled in before the agent gets any credential
agent:        invoice-matcher
purpose:      match supplier invoices to POs
never:        post payments or edit vendor bank details
sponsor:      finance-ops-lead
owner:        team-ap-automation
autonomy:     acts-with-approval
identity:     spiffe://corp.example/agents/invoice-matcher
credentials:  short-lived only
tools:        [[email protected], [email protected]]
a2a_partners: none
kill_switch:  gateway client inv-match-01
review:       sponsor, every 90 days
retire_when:  idle 30 days, or project closes

Keep the file in the same repo as the agent's code. A change to the tool list or the scopes then becomes a pull request the sponsor can see, and the pipeline can refuse a build whose real tool list doesn't match the file. The same facts can travel with the artifact in a standard format, too. SPDX's AI profile has a field for an AI package's autonomy type, and CycloneDX has a model card object.

A governance rule in a document gets enforced when somebody remembers it. Written as code, it gets checked on every build. Part 2 put rules at the gateway, while the agent runs. This section puts the same idea earlier, with rules the pipeline checks before anything is deployed.

Open Policy Agent works well here because it keeps the decision apart from the enforcement. Your pipeline hands OPA some JSON, and OPA checks it against policies written in Rego. Conftest runs Rego against structured config, and its docs list Kubernetes configs, Tekton pipelines and Terraform code, so a registration file fits fine. Rules get unit tests with opa test. When someone breaks a rule, the build fails, the same as it would for broken code.

Cedar is the other common pick, and Amazon Verified Permissions uses it. Its evaluation order is handy for hard limits. Any matching forbid policy means deny. Otherwise a matching permit allows the request, and if nothing matches, it's still a deny. So write the lines an agent must never cross as forbid rules. Nobody's permit added later can override them.

# runs in CI against the registration and build manifest
package agent.release
deny contains msg if {
  not input.registration.sponsor
  msg := "no sponsor, no release"
}
deny contains msg if {
  some t in input.build.tools
  not t in input.registration.tools
  msg := sprintf("tool %v not registered", [t])
}
deny contains msg if {
  input.build.static_keys
  not input.exception.approved
  msg := "static keys need an approved exception"
}

Keep the gates predictable. A Hacker News writer looking at AI-generated infrastructure code put it well: AI output is probabilistic, and compliance needs the same input to get the same policy decision every time. So let the agent be clever, and make the pipeline boring.

Every check in this post comes back to one question: which agent is this, really? A signature tells you who built an artifact, and a policy decision is only as good as the identity it was made for. The audit trail depends on it too. If an agent can borrow a teammate's key or a shared service account, every one of those checks attaches to the wrong thing.

So each agent gets its own identity, issued as part of deploy and never pasted in. SPIFFE gives a workload an ID and short-lived identity documents called SVIDs, X.509 certificates and JWTs among them. Its SPIRE implementation decides who gets one through attestation. Node attestation proves the machine, using evidence like a cloud instance identity document, a key held in a TPM or a Kubernetes service account token. Workload attestation then asks the node's kernel or kubelet which process is calling and compares the answer with what was registered. The agent proves where it runs, and nobody has to hand it a secret.

That's the answer to a problem people keep running into, usually called secret zero. On HashiCorp's forum, someone running Vault Agent on a long-lived VM in an air-gapped banking setup asked how to keep re-authenticating with AppRole without leaving a secret_id on disk, which they said turns it into a static password. The first reply pointed at platform-based auth. A later one suggested TPM or vTPM infrastructure and bootstrap certificates registered before anything gets access to the machine. If your agents will run somewhere with no cloud or Kubernetes to vouch for them, decide that at design time.

Keep identities apart by environment as well. OWASP's NHI8 warns that reusing the same NHI across test and production causes real problems, and NHI6 covers CI credentials that leak through repos, logs and config files. Installers leak them too. NVD's entry for CVE-2026-78627 describes an Okta integration installer that recorded its OAuth client secret in plaintext in the installer log, the Windows Application Event Log and the process command line. Any secret you pass in at install time can end up somewhere like that, which is one more reason to issue identity through attestation.

Identity and permission are different jobs, and it helps to keep them apart. A Hacker News commenter put it neatly: SPIFFE gives you workload identity and attestation, and it isn't a delegation framework. Let it answer who the agent is, and let something else answer what it may do. Here, that something else is part 2's tokens and policy. Another commenter raised the harder case. SPIFFE assumes you control where workloads run, while agents built by third parties cross organizational boundaries. For those, the registration has to say whose identity system vouches for the agent.

Assurance is the evidence that your controls actually work, and it's a separate thing from the controls. A design review is a control. The signed record of that review, linked to the build that went out, is assurance. Without that record, an auditor has to take your word for the review.

Be careful what you count as evidence. OWASP's supply chain entry for LLM applications says model cards and their documentation tell you about a model but don't guarantee where it came from. Its advice is to use models from verifiable sources and to check integrity with signatures and file hashes. A model card is a claim. A signature checked at deploy time is evidence.

NIST's AI RMF builds testing in from the start. It calls the work TEVV, short for test, evaluation, verification and validation, and says that run regularly across the lifecycle it allows for fixes mid-course and risk management after the fact. MEASURE 2.7 asks for a system's security and resilience to be evaluated and documented. MEASURE 1.3 wants internal experts who weren't front-line developers on the system, or independent assessors, involved in regular assessments. The Generative AI Profile adds red-teaming against prompt injection, data poisoning and model extraction, among other attacks.

ISO/IEC 42001 sits around all of this. It sets requirements for setting up, running, maintaining and continually improving an AI management system, for any organization that provides or uses AI. We use the AIDLC to give that management system something concrete to point at, a stage and a gate and a record for every agent.

• The approved registration file and the design review decision. Put the reviewer's name on it, because auditors ask
• Build provenance and the AI BOM, signed. SSDF task PS.3.1 suggests keeping them apart from the release files
• Test results tied to the build, policies and red-team runs included. If the build hash doesn't match, the results don't apply
• Admission's decision log for that release, and the identity it got. An auditor asking who let it in gets a one-line answer
• Drift findings and kill-switch drill results, once it's running. Parts 1 and 2 cover how to get them
• At retirement, the revocation record. Add a pointer to the archived release so nobody has to dig for it

Start with new agents and the two gates that matter most, then work back into the agents you already run. Each step below is useful on its own, so you can stop after any of them and still be better off than you were.

We'd start with the template. We'd sit down with one team, fill in a registration for an agent they're about to build and turn it into the first pipeline gate together. Then we'd add signing, attested identity and the evidence pack a step at a time. Our AI governance, AI security and DevSecOps pages explain how we work, and machine and workload identity covers the identity side.

Start with the tools you've got. We'd do the identity work on Microsoft Entra ID, Okta, HashiCorp Vault or CyberArk, and agents on Amazon Bedrock, Microsoft Foundry or Google Vertex AI go through the same gates. Bring in engineers for the build, or begin with an assessment of how your agents get made now.