Agent identity and access

Yes, and from the first pilot rather than at production. Tenhaw treats a distinct identity per agent as a day-one design decision on Agentic Design Team work, rather than something added before go-live. Running an agent under a developer's credentials or a shared service account attributes its actions to a human who did not take them, makes agent activity invisible in logs, and is materially more expensive to unpick later than to design correctly at the start.

By propagating source-system permissions through to query time, so retrieval respects the permissions of the asking user rather than those of the account that indexed the corpus. This is the most common serious failure in enterprise retrieval, and because it is usually discovered after indexing it often means rebuilding the index. It belongs in the design, not in hardening.

Everything that was a shortcut becomes a control failure. Shared credentials stop being a tidiness issue and start meaning that no log can attribute an action to a specific agent. Standing permissions granted for convenience add up to a combined blast radius nobody has calculated. Retrieval indexes built with an ingestion account's privileges multiply into a leak surface across every corpus. And revocation, which was one person and a console, becomes a question of who is on call at three in the morning for thirty systems. The organisations that scale AI agents across the enterprise are the ones that made identity, permission propagation, action logging and revocation a shared platform concern before the second agent, rather than solving it per agent thirty times.

Managing the identities, credentials, permissions and lifecycle of things that are not people (service accounts, workloads and now AI agents) with the same rigour applied to human identity. It has risen sharply up the security agenda because agents that call tools take consequential actions with real authority, and because the population was already unmanaged before agents arrived. A 2026 survey of 2,930 IT and security leaders put machine identities at 109 for every human, and found that 96% of human users already hold access beyond what their role requires.

Run it locally against mocked services, or in a dedicated hosted environment, on synthetic data built to exercise the real use cases rather than on production records. It removes the hardest approval from the fastest-moving phase of the work and lets the identity and access design be settled before anything sensitive is in scope. Combined with static analysis, dependency and secrets scanning in the pipeline and a model-led security review roughly every fifth prompt during the build, proofs of concept produced this way are frequently more compliant than the legacy systems they sit next to. This is Tenhaw's own default on pilot work, with the security function involved from design concept and agreeing the limited scope up front.

At design concept, agreeing the scope, rather than at review. Tenhaw works that way on its own engagements, with the security function involved from the design concept and agreeing the limited scope up front. It is a sequencing choice that costs almost nothing and turns the security function into a co-author of the control design instead of the last gate before a committed date, where its only available lever is to block.

How do we revoke it, who is authorised to do that, and when was it last tested. If the answer involves locating the person who deployed the agent, there is no control, and untested revocation is not a control either. The second question is what the blast radius is if this agent is manipulated, which is answerable only if permissions are scoped to the task rather than to the agent.

Permissions scoped to the task rather than to the agent, with time-boxed credentials that expire. The design question is what this agent needs, for this task, for this long. If the agent is then manipulated through prompt injection or makes a reasoning error, the damage is bounded by the task at hand rather than the agent's entire permission set, which is what makes the blast radius calculable. Broad standing access granted because it is simpler is the shortcut that quietly stops organisations scaling agents later, so Tenhaw treats task-scoped, expiring credentials as a design requirement from the first pilot rather than a hardening step.

No, and this is one of the few areas where the differences between providers genuinely matter. The agent identity primitives, the way they federate with an existing enterprise directory, and how far permission propagation is supported natively rather than built all vary meaningfully across the hyperscalers. The design principles are provider-independent: a distinct identity per agent, task-scoped credentials that expire, source permissions propagated through to query time, actions logged against the agent, and a tested revocation path. The implementation is not, so the engineering effort, and how much you build rather than configure, will differ depending on which platform you are on.

Partly, and the gap is in the definitions rather than the tooling. In most organisations the definition of a privileged user still means a person, while an agent is a non-human identity with real authority, and one that decides for itself what to do with the access it holds. The disciplines your IAM function already runs transfer directly: enumerable identities, least privilege, logging, revocation. What does not transfer is the shared service account habit, which attributes an agent's actions to a principal that did not take them and is expensive to unpick once actions have accumulated. Where deep identity engineering is required, Tenhaw would expect to work alongside your IAM function or a specialist, not around them.

A service account is a shared, general-purpose principal that runs a fixed job, usually with standing broad privileges and no way to tell from the logs what triggered it. An agent identity is distinct and enumerable, held by one agent, never shared with a human, scoped to the task rather than to the system it touches, and issued with credentials that expire. The distinction matters because an agent, unlike a script, decides for itself what to do with the access it holds, so both the record of what it did and the bound on how far it could go have to be designed in rather than reconstructed afterwards.

LLM06, Excessive Agency, is the entry in the 2025 OWASP Top 10 for large language model applications covering an agent that holds more permission, functionality or autonomy than its task requires, so a manipulated or mistaken model can act well beyond the job in hand. It is the standards-body version of the argument for scoping permissions to the workflow rather than to the agent, with credentials that expire. Its companion, LLM08, Vector and Embedding Weaknesses, covers the retrieval side. Both are useful references when a control design needs to carry weight with a risk committee rather than be argued from first principles.

Security trimming is the pattern where every indexed document carries an identity field and the search filters results at query time against the group membership of the person asking, so an assistant can only answer from documents that person could already open. Microsoft documents it for Azure AI Search, named here as one provider's worked example rather than as a recommendation of that provider. It works, provided the decision is taken before the corpus is indexed and the filter is evaluated against the source system rather than against a copy of the permissions made at ingestion. What it does not do is bound what the agent may then act on, which is a separate question about task-scoped permissions.

Start by establishing what that account can actually reach, because the answer is almost always broader than anyone expects, and that permission set is your current blast radius. Tenhaw takes this on as Agentic Design Team work. Then move the agents onto distinct identities of their own before you add the next one, since unpicking attribution once actions have accumulated against the wrong principal is materially more expensive than designing it in. Alongside that, agree who is authorised to revoke an agent's access and test the path. One agent on shared credentials is survivable. The trap is arriving at thirty of them and being unable to say which one took a given action.

Four roles, and the sequence matters more than the headcount. The security function comes in at design concept and agrees the scope, so it co-authors the control design rather than gating it the week before a committed date. Your IAM function, or a specialist alongside it, owns the identity engineering itself, and the sensible posture is to work alongside them rather than around them. The workflow owner is the only person who can say what the agent needs, for this task, for how long. And one named human is accountable for the agent, which includes being explicit about who may switch it off.

You will have more identities, and that is the right trade. Sprawl is not really a counting problem so much as an enumeration problem. The machine identity population in most organisations was already large and largely ungoverned before a single agent joined it, and the failure is that nobody can say what any given principal is permitted to do. Distinct identities per agent, scoped to the task and expiring, make the population enumerable and the blast radius calculable. The alternative, one shared account behind everything, means fewer identities and no attribution at all, which is the version that becomes unmanageable at thirty agents rather than at three.

Less than retrofitting it. Distinct identities and task-scoped permissions are cheap at design time and expensive once actions have accumulated against the wrong principal. Most of what it costs is sequencing rather than engineering, since the decisions that matter are taken before anything is indexed or deployed. Tenhaw publishes the method in full and free to adopt, so a team with a functioning IAM practice can apply this design without hiring anyone, and where deep identity engineering is bought it runs alongside your own IAM function or a specialist rather than around them. Engagements are retainer-shaped, and a month that delivers no measurable value is reported as a failed month.