If identity engineering adds a meeting to your calendar, it is dead on arrival.
This is not a hypothetical. Teams already spend 5 to 7 percent of their sprint capacity on ceremony overhead, and in the worst cases that number climbs to 22.5%. Developers burn 17+ hours per week on maintenance, with documentation consistently deprioritized because it does not ship features. Forty-two percent of a developer's week goes to tech debt and bad code, costing an estimated $85 billion worldwide.
Your team is already overloaded. Any practice that requires its own process, its own review committee, or its own standing meeting will be abandoned within two sprints. Identity engineering survives only if it dissolves into workflows the team already runs.
Here is how to make that happen.
Where declarations live
Identity declarations belong in version control, next to the code they describe. Not in a wiki. Not in a Confluence page that was last updated eight months ago. Not in a shared drive. In the repo, tracked by git, subject to the same review and history as everything else.
This is the docs-as-code model adopted by Google, AWS, Spotify, and Squarespace. The insight behind it is simple: documentation that lives outside the development workflow drifts from reality. Documentation that lives inside the workflow has the same forces acting on it as the code. When a developer opens a PR, the declaration file is right there. When an agent needs context, the declaration is discoverable without leaving the repo.
A service identity declaration is a file. It sits in the root of a service directory or in a conventions directory alongside linting configs, CI definitions, and infrastructure code. It declares what the service is, what it does, what it refuses to do, what guarantees it makes, and what dependencies it trusts. The format matters less than the location. YAML, TOML, Markdown with structured frontmatter, whatever your team will actually maintain. The only hard requirement is that it lives where the code lives.
This solves the maintenance problem by converting identity work from a separate activity into a side effect of development. You do not schedule time to update declarations. You update them when you change the thing they describe, in the same PR.
When declarations change
Declarations change at three points in the sprint cycle, each with a different purpose.
During sprint planning, teams set intent. If a sprint includes work that changes what a service is or does (new capabilities, new integrations, new trust boundaries), the planning conversation should name that shift. Not as extra process. As part of the story definition. "This story adds a Stripe integration" implies a change to the service's dependency trust boundary. Writing that down during planning means the PR reviewer knows to look for it later.
During PRs, teams implement changes. This is where declaration updates actually happen. A developer changing the service's behavior updates the declaration in the same commit. A reviewer checks whether the declaration still matches the implementation. This is no different from reviewing whether a test still matches the code. It is the same skill applied to a different artifact.
During incident response, teams discover gaps. An incident reveals that the service did something nobody expected. The postmortem asks why, and the answer is often that the behavior was never declared. The fix is not just a code patch. It is a declaration update that closes the gap, making the boundary explicit so that future changes (and future agents) know it exists.
Fifty-eight percent of teams use two-week sprints. In a two-week cycle, planning happens on day one, PRs flow continuously through the sprint, and incidents happen whenever they feel like it. Identity declarations touch all three without requiring their own ceremony.
How CI validates identity
The model here is Terraform. If you have used Terraform in a team, the workflow is familiar: you write a declaration, open a PR, CI runs validation automatically, and the results appear as comments on the PR before anyone reviews it.
HashiCorp's recommended CI workflow runs four checks on every PR: format validation, syntax validation, linting, and security scanning. The plan output (what will change and how) gets posted as a PR comment so reviewers see the impact before approving. Nobody schedules a meeting to review Terraform plans. The automation surfaces the information where the decision is being made.
Identity declarations can follow the same pattern. CI checks on a PR can validate that declarations are syntactically correct, that they are consistent with each other across service boundaries, that claimed dependencies match actual imports, and that stated boundaries are not violated by the code in the PR. The results show up as PR comments or status checks. The reviewer sees them alongside the code diff. No extra step.
The most effective governance integration point is during the PR, before merge to main. Not after deployment. Not in a quarterly audit. At the moment when someone is already looking at the change and deciding whether to approve it. Identity validation that runs here is governance you get for free, because the review is already happening.
The GitOps pattern for identity
GitOps takes the CI model one step further. In a GitOps workflow, the repository is the source of truth. Changes happen through PRs. Merge triggers reconciliation. Tools like ArgoCD and Flux continuously compare the declared state in the repo against the actual state of the system and correct any drift.
Apply this to identity. The declaration in the repo says what the service is supposed to be. CI validates the declaration against the code on every PR. On merge, a reconciliation process checks whether the running system matches the merged declaration. If something drifts (a new dependency appears that was never declared, a boundary gets crossed that should not be), the reconciliation flags it.
This is not science fiction. Policy-as-code tools already do a version of this. Open Policy Agent, Kyverno, Pulumi, and Cloud Custodian account for 82% of policy-as-code repositories, and 85% of teams that adopt policy-as-code stick with a single tool. The pattern is proven. What changes with identity engineering is the scope of what gets declared and validated. Not just infrastructure policy, but service identity: purpose, boundaries, guarantees, trust relationships.
The GitOps loop for identity looks like this:
- A developer declares or updates a service identity in the repo.
- They open a PR. CI validates the declaration against the code.
- A reviewer approves (or requests changes, like any other PR).
- On merge, the reconciler compares the declared identity against the live system.
- Drift gets flagged. Depending on policy, it gets corrected automatically or queued for human review.
Every step uses a tool the team already has. Git, PRs, CI, a reconciler. No new meeting. No new role. No governance committee.
What not to do
There are three patterns that will kill identity engineering adoption.
The first is a separate governance process. If declaration reviews happen outside the PR workflow, in a different tool, with a different set of reviewers, on a different schedule, they will be treated as overhead. They will be skipped under deadline pressure, which is always. Governance that is separate from development is governance that is optional in practice.
The second is a review committee. A group of senior engineers or architects who must approve every declaration change creates a bottleneck. It also sends a message: declarations are someone else's job. The team stops thinking about identity because the committee owns it. The committee becomes overloaded. Reviews get delayed. Developers start working around the process.
The third is mandatory declaration review on every PR. Not every PR changes the service's identity. A CSS fix does not need a declaration review. A dependency bump might, but most do not. If your CI is checking consistency automatically, you do not need a human to review declarations that have not changed. Reserve human review for PRs that actually modify what the service is or does. Let automation handle the rest.
The common thread: anything that adds friction without adding signal will be routed around. Engineers are extremely good at routing around friction. Design for that tendency instead of fighting it.
Monday morning
Three changes. None of them add a meeting.
First, move your service's identity declaration (wherever it currently lives) into the repo. If you do not have one, write a short file that states what the service does, what it does not do, what its critical guarantees are, and what it trusts. This takes thirty minutes for a service you know well. Put it next to your README or your infrastructure config.
Second, add a CI check that runs on PRs touching the declaration file. Start simple: validate the format, check for empty required fields, compare the declared dependencies against what the code actually imports. You can make this more sophisticated over time. The point is to have something that runs automatically so that declaration changes get the same mechanical validation as code changes.
Third, during your next sprint planning, look at the stories on the board and ask which ones change what the service is or does, not just how it behaves. Flag those stories. When those PRs come in, reviewers will know to check the declaration alongside the code.
That is it. Three workflow adjustments, each piggybacking on something the team already does. No new ceremony. No new tool. No committee. Just identity engineering where it belongs: inside the sprint, not alongside it.
The best process change is the one nobody notices because it fits inside the process they already have. We are building tooling that makes identity declarations a natural part of the development workflow, not an extra step.