Agent identity and access, answered in full.

Yes, and from the first pilot rather than at production. 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 2025 study of 2,600 security decision-makers put machine identities at 82 for every human, with 42% of them holding privileged or sensitive access and 88% of respondents saying their organisation still defines a privileged user as a person.

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. That 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.

At design concept, agreeing the scope, rather than at review. It is a sequencing choice that costs almost nothing and changes the entire dynamic: the security function becomes 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.