[{"data":1,"prerenderedAt":371},["ShallowReactive",2],{"blog-\u002Fblog\u002Fagent-identity-and-permissions":3,"blog-related-\u002Fblog\u002Fagent-identity-and-permissions":348,"blog-surround-\u002Fblog\u002Fagent-identity-and-permissions":370},{"id":4,"title":5,"audience":6,"body":10,"cluster":311,"conversionGoal":312,"cornerstone":313,"date":314,"description":315,"draft":316,"extension":317,"factCheckedAt":312,"faq":318,"featured":316,"language":312,"meta":328,"minRead":329,"navigation":313,"order":330,"originalAsset":312,"path":331,"pillar":332,"primaryKeyword":333,"publicationOrder":334,"relatedProject":312,"releaseScope":312,"reviewCycle":335,"reviewMethod":336,"reviewStatus":337,"reviewedAt":314,"reviewedBy":338,"searchIntent":339,"seo":340,"sources":312,"stem":341,"tags":342,"type":346,"updated":314,"__hash__":347},"blog\u002Fblog\u002Fagent-identity-and-permissions.md","Agent Identity: Who Is the AI Acting As?",[7,8,9],"enterprise-architect","engineering-manager","transformation-lead",{"type":11,"value":12,"toc":302},"minimark",[13,21,30,35,38,44,47,53,59,62,68,173,180,184,187,193,199,205,211,217,228,239,243,246,249,252,260,264,267,270,278,282,285,288],[14,15,16,20],"p",{},[17,18,19],"strong",{},"Every AI agent that touches an enterprise system is acting as somebody."," That is not a philosophical statement, it is a technical one: a call arrives at a system, it carries a credential, and the system writes something in a log about who did it. Whether anyone chose that identity deliberately is a different question, and in most designs it is not chosen at all. The agent acts as whatever credential was available when the integration was built, which usually means a technical account with rights that accumulated over years for reasons nobody remembers.",[14,22,23,24,29],{},"The uncomfortable version of the question arrives later, and it always arrives in the same form. Somebody looks at a record that changed, asks who changed it, and the answer is a service account name. That is the moment the identity decision gets made — retrospectively, expensively, under scrutiny. It is much cheaper to make it at design time, straight after you have decided ",[25,26,28],"a",{"href":27},"\u002Fblog\u002Fhow-ai-agents-fit-into-existing-enterprise-systems","where the agent sits relative to the systems"," at all.",[31,32,34],"h2",{"id":33},"four-things-an-agent-can-act-as","Four things an agent can act as",[14,36,37],{},"There are really only four options, and every design is one of them or a combination.",[14,39,40,43],{},[17,41,42],{},"The user's delegated identity."," The agent acts on behalf of the person who asked, carrying that person's rights and no more. It is the most honest model of what is actually happening — a person wanted something done, and a machine did it for them — and it inherits the whole existing authorisation estate for free. Whatever that user could not do, the agent cannot do either, without anyone building a second permission model.",[14,45,46],{},"Its weakness is that the audit trail stops being believable. The log says a named person performed four hundred actions between 02:00 and 02:06, and the person will tell you, truthfully, that they were asleep. Attribution is technically correct and practically misleading, unless the record also carries the fact that an agent performed it on their behalf. Revocation is blunt too: stopping the agent means interfering with the person.",[14,48,49,52],{},[17,50,51],{},"A shared service identity."," One technical account serves the agent, and usually several other things as well. It is the default because it already exists, and it is the worst of the four for exactly that reason. Its rights are the union of everything that has ever needed it, which makes the blast radius unknowable without an investigation. Attribution is gone — the log shows the account, not the request or the requester. And revocation is unusable in an incident, because switching the account off also stops three interfaces nobody has mapped.",[14,54,55,58],{},[17,56,57],{},"An agent-specific identity."," The agent has its own account, used by nothing else, scoped to precisely the objects and operations its job needs. Attribution is clean. Blast radius is bounded by design rather than by history. Revocation is surgical: disable it and the agent stops, and nothing else does. This is the model I would reach for by default for anything that writes.",[14,60,61],{},"The trade-off is that the rights are standing. They exist at three in the morning when nobody is asking for anything, which means the credential itself is now an asset worth protecting, and a scope that was right at go-live will drift as the agent's job grows.",[14,63,64,67],{},[17,65,66],{},"A temporary scoped credential per task."," The agent is issued rights for one piece of work, narrowed to that work, valid for a short window, and then gone. This is the strongest position — least privilege expressed in time as well as in scope — and it is the most work to build, because something has to decide what the scope for this particular task is, and be right.",[69,70,71,93],"table",{},[72,73,74],"thead",{},[75,76,77,81,84,87,90],"tr",{},[78,79,80],"th",{},"Identity model",[78,82,83],{},"Attribution",[78,85,86],{},"Blast radius",[78,88,89],{},"Revocation",[78,91,92],{},"What an audit sees",[94,95,96,116,135,154],"tbody",{},[75,97,98,104,107,110,113],{},[99,100,101],"td",{},[17,102,103],{},"Delegated user",[99,105,106],{},"Names a person, misleadingly",[99,108,109],{},"That user's full rights",[99,111,112],{},"Blunt — hits the person too",[99,114,115],{},"A human who did impossible volumes",[75,117,118,123,126,129,132],{},[99,119,120],{},[17,121,122],{},"Shared service account",[99,124,125],{},"None",[99,127,128],{},"Unknowable without investigation",[99,130,131],{},"Unusable — breaks other consumers",[99,133,134],{},"An account, and no way back to a requester",[75,136,137,142,145,148,151],{},[99,138,139],{},[17,140,141],{},"Agent-specific",[99,143,144],{},"Clean, per agent",[99,146,147],{},"Bounded by an explicit scope",[99,149,150],{},"Surgical",[99,152,153],{},"An agent, and whoever it acted for if you kept it",[75,155,156,161,164,167,170],{},[99,157,158],{},[17,159,160],{},"Temporary scoped",[99,162,163],{},"Clean, per agent and per task",[99,165,166],{},"Bounded per task and in time",[99,168,169],{},"Expiry does most of the work",[99,171,172],{},"An agent, a task, and the scope it was given",[14,174,175,176,179],{},"The pattern worth stealing, if you build nothing else, is an agent-specific identity ",[17,177,178],{},"bounded by"," the requesting user's rights: the action attributes to the agent, and the agent may not exceed the person who asked. You get clean attribution and surgical revocation, and you inherit the existing authorisation model as a ceiling rather than rebuilding it.",[31,181,183],{"id":182},"the-questions-that-actually-decide-it","The questions that actually decide it",[14,185,186],{},"Four options is not a design. These questions are.",[14,188,189,192],{},[17,190,191],{},"May an agent act with permissions its requesting user does not have?"," Usually the answer should be no, and where it is yes, that must be a deliberate, narrow, documented exception rather than a side effect. The failure mode is specific and it is not exotic: an agent with broad standing rights becomes an accidental privilege-escalation route, where asking it nicely accomplishes something the asker could not do directly. Nothing was hacked. The agent did its job. The organisation simply built a door beside the one it had locked.",[14,194,195,198],{},[17,196,197],{},"May an agent approve its own proposal?"," No — and the reason is not about the agent's quality. Segregation of duties has never been a statement about competence. A trusted employee of twenty years is also not permitted to approve their own posting, because the control buys a second, independent look, and one actor doing both halves removes it entirely. An agent that drafts and then approves is a single identity performing maker and checker while the workflow diagram still politely shows two boxes. The same holds for two agents built from the same design reviewing each other; independence is the point, and two instances of one thing do not have it.",[14,200,201,204],{},[17,202,203],{},"How is the scope bounded?"," To the smallest set that lets it finish its actual job, defined as a list rather than a category. \"Read access to finance data\" is not a scope; a named set of objects with named operations is. Two habits keep it honest: grant nothing \"for now\" during the pilot, because pilot access is production access with a friendlier name, and re-derive the scope from what the agent has genuinely used rather than from what somebody thought it might need.",[206,207,208],"pull-quote",{},[14,209,210],{},"An audit does not ask what the agent was permitted to do. It asks who did this — and a shared service account has no answer.",[14,212,213,216],{},[17,214,215],{},"What happens when the person changes role or leaves?"," Under delegated identity the existing leaver process largely handles it — provided disabling the account also revokes the agent's outstanding tokens, which is worth checking rather than assuming. Under a standing agent identity, nothing happens at all — and that is the honest weakness of the model I just recommended. The access outlives the employee, then outlives the reorganisation, and eventually nobody in the building can tell you why it exists. So every agent identity needs a named owner who is not the person who built it, a review on a real cycle, and where possible an expiry that forces the conversation rather than waiting for one.",[14,218,219,222,223,227],{},[17,220,221],{},"Who can revoke it, and how fast?"," In an incident, the useful question is not whether revocation is possible but whether the person on call at 22:00 on a Friday can do it without a change request, and knows they can. That is a runbook and a rehearsal, not an architecture diagram. It is also the identity-shaped half of the kill switch described in ",[25,224,226],{"href":225},"\u002Fblog\u002Fthe-enterprise-ai-control-layer","the control layer",": stopping the agent and revoking its rights are two different actions, and you want both.",[14,229,230,233,234,238],{},[17,231,232],{},"What must the log contain?"," Enough for someone with no context to reconstruct a specific action six months later. In practice that is: who requested it, which identity executed it, what the agent proposed, what it actually did, which scope permitted it, which approval covered it if one was required, and which prompt and model version produced the proposal. The test I would apply is simple — hand a single record to someone who has never met the system and ask them to explain why it changed. If they need you in the room, the log is decoration rather than evidence, and the ",[25,235,237],{"href":236},"\u002Fblog\u002Fproduction-ai-observability","observability work"," has not been done.",[31,240,242],{"id":241},"read-propose-execute","Read, propose, execute",[14,244,245],{},"Identity gets easier to reason about when you stop treating \"access\" as one thing. An agent doing genuinely useful work usually needs three different levels of authority in the same workflow, and they can carry different identities.",[14,247,248],{},"Reading is broad and low-consequence, though not zero-consequence: an agent that can read is an agent that can surface something to whoever asks, and enterprise content permissions were designed on the assumption that a human would have to know where to look.",[14,250,251],{},"Proposing needs almost nothing. A proposal is a record in a queue. It should not require any right in the target system at all, which is why propose-and-queue is such a comfortable placement — the agent's identity there is nearly powerless by construction.",[14,253,254,255,259],{},"Executing is where the whole question lives, and it should be the narrowest identity in the design, used for the shortest possible list of operations. Separating the three means the agent is not carrying execute-level rights while doing read-level work, which is most of what it does most of the time. Mapping this properly is part of laying out ",[25,256,258],{"href":257},"\u002Fblog\u002Fanatomy-of-an-ai-native-enterprise-workflow","the workflow end to end"," rather than describing the agent as a single actor with a single set of keys.",[31,261,263],{"id":262},"earning-it","Earning it",[14,265,266],{},"The instinct, when an agent works well, is to widen its identity. It has been right for two months, the queue is long, the approvals feel like ceremony — so give it more.",[14,268,269],{},"I would invert the test. The evidence that an agent should get a wider identity is not that its outputs have been good. It is that it has repeatedly demonstrated it does not need the wider identity: its proposals fall inside a narrow scope, it stops rather than improvising when something is outside its remit, its exceptions route correctly, and the approvals it collects almost never change what it proposed. An agent that keeps bumping into its scope is telling you the scope is wrong; an agent that has never needed to bump into it is the one that can be trusted with more.",[14,271,272,273,277],{},"That is not caution dressed up as principle. It is the same standard any organisation applies to people, and it comes from the same place as the argument that ",[25,274,276],{"href":275},"\u002Fblog\u002Fwhy-enterprise-ai-is-an-architecture-problem","enterprise AI is an architecture problem",": authority is granted against demonstrated behaviour, not against enthusiasm.",[31,279,281],{"id":280},"what-i-would-decide","What I would decide",[14,283,284],{},"Choose the identity model explicitly and write down why, because the default is a shared account and the default is the worst option available. Prefer an agent-specific identity, bounded by the requesting user's rights, so attribution is clean and the existing authorisation estate acts as the ceiling. Move to temporary scoped credentials wherever the work divides into tasks cleanly enough to make it real. Never let an agent approve its own proposal, or exceed the person who asked, without a documented exception someone signed. Give every agent identity an owner, a review cycle and an end date. Rehearse revocation before you need it. And log at the grain of a single action, because the question that eventually arrives is never about averages — it is about one record, one day, and whose name is on it.",[286,287],"hr",{},[14,289,290],{},[291,292,293,294,297,298,301],"em",{},"See also ",[25,295,296],{"href":225},"the enterprise AI control layer"," and ",[25,299,300],{"href":27},"how AI agents fit into existing enterprise systems",".",{"title":303,"searchDepth":304,"depth":304,"links":305},"",2,[306,307,308,309,310],{"id":33,"depth":304,"text":34},{"id":182,"depth":304,"text":183},{"id":241,"depth":304,"text":242},{"id":262,"depth":304,"text":263},{"id":280,"depth":304,"text":281},"architecture",null,true,"2026-08-19","Delegated, shared, agent-specific or temporary — the four identities an AI agent can act under, and what each one costs you in attribution and blast radius.",false,"md",[319,322,325],{"question":320,"answer":321},"Should an AI agent use the user's identity or its own?","It depends on which property you need most. Acting under the requesting user's delegated identity is honest about who wanted the work and inherits their limits automatically, but the trail then shows a person doing things at a volume and hour no person did, and revoking the agent means touching the person. An identity of its own attributes cleanly, can be scoped to exactly its job, and can be switched off without disturbing anyone — at the cost of a standing set of rights that exists whether or not anyone is asking. Many designs need both: the agent's own identity, bounded by the requesting user's.",{"question":323,"answer":324},"Can an AI agent approve its own proposal?","No, and the reason has nothing to do with how good the agent is. Segregation of duties exists because one actor doing both halves removes the second look entirely, and the control was never a judgement about competence — a trusted employee is also not allowed to approve their own posting. An agent that drafts and then approves is one identity performing maker and checker, so the control is gone even though the workflow diagram still shows two steps. The same applies to two agents from the same design: independence of judgement is what the control buys, and two instances of one model do not have it.",{"question":326,"answer":327},"What happens to an AI agent's access when an employee leaves?","That depends entirely on how the identity was set up, which is why it is a design question rather than an operational one. If the agent acts under delegated user identity, a leaver process that disables the account generally stops the agent too — though only once the outstanding tokens are revoked rather than left to expire. If it holds its own standing rights that were granted because a particular person sponsored them, nothing happens at all — the access survives the person, and it usually survives the reorganisation after them. Any agent identity needs an owner, a review cycle and a defined end, or it quietly becomes permanent.",{},9,2.6,"\u002Fblog\u002Fagent-identity-and-permissions","enterprise-ai-systems","AI agent identity permissions",214,"annual","editorial","reviewed","Tan Gravam","informational",{"title":5,"description":315},"blog\u002Fagent-identity-and-permissions",[343,344,345],"ai-agents","enterprise-ai","controls","text","M9T1vJ94YSkqw7bK7ZnHQDkwwEf_HNfWu_7G84yhfB4",{"related":349,"prev":361,"next":363,"hasOrder":313,"place":366},[350,354,357],{"path":351,"title":352,"description":353},"\u002Fblog\u002Fai-evaluation-and-regression-testing","Enterprise AI Evaluation & Regression Testing","How I build eval sets for AI running inside an enterprise — cases, scoring, a regression gate — so a prompt or model change is judged on evidence, not vibes.",{"path":236,"title":355,"description":356},"Production AI Observability in the Enterprise","You can't fix what you can't see. How I observe AI running inside an enterprise — quality, cost, latency, drift and failures — as data, not complaints.",{"path":358,"title":359,"description":360},"\u002Fblog\u002Fprompt-and-model-versioning","Prompt & Model Versioning: Enterprise AI Governance","A prompt is production code and a model is a dependency you don't control. How I version prompts, handle model changes and stop silent regressions.",{"path":225,"title":362,"type":346,"language":312},"The Enterprise AI Control Layer",{"path":364,"title":365,"type":346,"language":312},"\u002Fblog\u002Fai-output-contracts-and-failure-handling","AI Output Contracts and Failure Handling",{"label":367,"position":368,"total":368,"hub":369},"Architecture",4,"\u002Ftopics\u002Fenterprise-ai-systems",[],1787146313807]