Imagine you're reviewing a new background worker in a payments application.
The implementation looks fine - it processes messages, handles retries and passes its tests.
Then you notice something in the infrastructure configuration.
The worker is using the same cloud identity as the payments API.
Both services work as expected, nothing is broken but, should a background worker have access to everything the payments API can access?
What would you actually need to check?
I'd start with three things.
1. Which identity is each workload actually using?
Look at the deployment configuration and IaC. A reference in the application doesn't necessarily tell you which identity is assigned in the deployed environment.
2. What can those identities access?
You need to understand the permissions attached to the identity, the resources they apply to and any additional policies or restrictions that affect access. If both workloads share an identity, changing the permissions could affect both services.
3. Why were the permissions designed this way?
Perhaps the workloads originally had similar responsibilities, or sharing the identity was intentional. Or maybe the system evolved and nobody revisited the original decision.
The configuration tells you what exists but it doesn't tell you why, and without that context, even a well-intentioned fix could introduce another problem.
Now imagine the change is being made by an AI agent
An engineer asks a coding agent to add a background worker to process payment events. The agent writes the code, updates the infrastructure configuration, runs the tests and opens a PR.
Or, in a workflow where it has deployment authority, it might go further and deploy the change.
Everything succeeds but, suppose the agent reused an existing cloud identity because it was already available in the project.
That decision might be technically valid and it might even be consistent with patterns elsewhere in the codebase.
What it doesn't establish is whether the new worker should inherit the permissions associated with that identity. If the original architectural constraints weren't available to the agent, how would it know that the two workloads were meant to have different access?
And if the pipeline only checks whether the configuration is valid and the application works, the change could pass without that design decision being examined.
This isn't a problem unique to AI-generated code, engineers make the same kinds of decisions.
The difference is that agents can now produce and, where authorised, deploy changes with much less human involvement. The architectural evidence and constraints need to be available within those workflows, rather than depending on someone remembering to investigate afterwards.
Imagine this across 80 services
Inspecting one cloud identity manually is relatively straightforward. but, what happens when you're working across dozens of services, repositories, cloud accounts and deployment pipelines?
A permission might be defined in Terraform, referenced by a deployment workflow and used by several services. A new integration is introduced, another workload is added, or an agent updates the infrastructure configuration.
Someone (or something) needs to establish which relationships have changed, whether they remain appropriate and what else might be affected by correcting them, and that understanding needs to stay current.
It's not that engineers don't know how to investigate these things, it's that the evidence is distributed across different systems, and the investigation often has to be repeated as software evolves.
Passing tests doesn't necessarily mean the design is correct
Tests can establish that a system behaves correctly under the conditions being tested. Architectural constraints can also be encoded into tests and policies.
But those checks can only assess what they've been designed to verify, if a requirement isn't captured, or a relevant relationship exists outside the context available to the engineer or agent, a successful test run may not reveal the concern.
And finding two workloads sharing an identity doesn't automatically establish a vulnerability. You still need to understand the available evidence, the intended requirements and the potential consequences before deciding whether something should change.
What we're building at Veriom
I'm building Veriom to make that system-level understanding part of how software is developed and changed, so we don't have to think about this again.
Veriom connects evidence from code, IaC and cloud environments into a living architectural model. It reconstructs how services, identities, dependencies and boundaries relate, assesses structural concerns against available requirements and controls, and provides evidence backed findings and remediations.
Rather than starting every investigation from scratch, engineers and agents can examine the relationships and the evidence behind them when deciding what needs changing.
We've put together an interactive system where you can explore the approach without connecting your own code:
We've also just launched self-onboarding for engineers who want to try Veriom with their own supported sources for free.
I'm interested in how other teams are approaching this. When coding agents make changes across services and infrastructure, are your architectural constraints available to them during development, or does someone still have to reconstruct that context during review?
