AI agents are arriving in engineering, and nobody can say what they can reach
If you cannot say what each agent can reach, as which identity, for how long — and who would notice if that changed — the access is not yet under control. That is an access problem, and access problems are solvable.
Usually raised by: CTO, platform lead or security owner introducing agents into engineering or production.
What normally triggers it: Coding agents arriving in the delivery pipeline, an automation granted credentials for an experiment, or a security review asking what the agents can reach.
- GitHub
- GitLab
- GitHub Actions
- AWS
You probably recognise some of these.
Not all of them, and not in this order. If three or four land, this is the page you want.
- An agent authenticates with a key that was created for a person, or shared from another system.
- Coding agents can open pull requests, and nobody has checked what else the token allows.
- Agent activity is indistinguishable from human activity in the audit trail.
- The honest answer to “what can the agents reach?” is a guess.
What is different afterwards.
An inventory of what each agent and automation can actually reach, access narrowed to what the job needs — scoped, short-lived and attributable — and a written position you can hand to a security review.
The work itself
- Inventory the agent and automation identities across cloud accounts, repositories, CI and the APIs in scope — including the shared and inherited credentials.
- Map what each one can actually do, from the policies and tokens rather than from what anyone intended.
- Replace shared and long-lived credentials with scoped, short-lived identity where the platform supports it.
- Separate agent identity from human identity, so the audit trail says which was which.
- Set expiry and review points, so access granted for an experiment does not become permanent by default.
- Write down the position: what agents may reach, what they may not, and who approves a change to it.
Who does it: an InfraEdge engineer, who walks your team through what was found and answers your reviewer on each change.
Two identities, kept apart.
Human identity
A person, through SSO
- Reviews and merges the pull request
- Approves what an agent may reach
- Access follows the person’s role
Agent identity
A named agent, with its own identity
- Scoped to the job it performs
- Short-lived — issued per run, expiring by default
- Attributable — the audit trail names the agent, never a person’s key
The end state the work builds — illustrative capability, not a client engagement.
Agent access mapped, and the riskiest paths closed
The agents and automations you name, across one estate — cloud accounts, repositories and CI.
Done when
Every named agent identity is inventoried with what it can reach; the agreed high-risk paths are closed through your review process; remaining access is scoped, time-bound and attributable to the agent rather than to a person; and the written access position has been reviewed by your named owner.
What you receive
- An inventory of agent and automation identities, and what each can actually reach
- The implemented access changes, as code in your repositories
- Agent identity separated from human identity in the audit trail
- A written agent access position you can hand to a customer or an auditor
What we need from you
- A list of the agents and automations in use — including the unofficial ones, which is usually where the surprises are
- A scoped read-only role for discovery, and a named reviewer for the changes
- A decision owner for what agents are allowed to do, which is a policy question before it is a technical one
What makes it larger or smaller for you.
The variables that drive the size, judged against your own estate.
Larger if
- Agents spread across several platforms — cloud, GitHub or GitLab, CI and third-party APIs, each holding its own credentials
- Shared credentials that humans and agents both use, so separating them touches working systems
- No existing identity federation, so short-lived access needs its foundation built first
Smaller if
- A small number of agents, each with a known owner
- Access already issued through a central identity provider
- CI already on workload identity, so the pattern exists and extends
We do not quote a duration for your estate before seeing it, and the scope you receive after the call names the package rather than an hourly rate.
What this does not include.
Stated here rather than discovered later.
- We do not evaluate models or the quality of what agents produce. The scope is what they can reach and change, not how capable they are.
- Prompt-injection and model security testing are specialist disciplines we do not sell. Where a review genuinely needs one, we will say so.
- This does not certify that your agent use is safe. It makes the access knowable, narrow and attributable — which is the prerequisite for any such judgement.
We only run a couple of coding agents. Is this not premature?
If you can already say which identity each agent uses, what it can reach and when that access expires, it is premature — do not buy it. The reason to look early: agent access accumulates like human access, one reasonable grant at a time, and the pattern is easier to set with two agents than to untangle later.
Problems that tend to arrive together.
Deploying depends on manual steps, or on one person being available
The goal is not more pipeline stages. It is that a release is the same event every time, that it can be undone, and that it does not need a particular person awake.
Accounts, identity and networking no longer fit the organisation
Usually the structure was right for the company that built it, and that company no longer exists.
Describe the project
Twenty minutes, no charge, with the engineer who would do the work. We work out whether this is the work you need and whether we are the right people — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.