{"post":{"slug":"agent-identity-and-auth-2026","title":"Agent Identity and Auth: Who Is the Machine Acting As?","excerpt":"An agent calling an API on your behalf needs credentials. Giving it yours makes every action indistinguishable from you, which is exactly the wrong outcome.","category":"ai","date":"August 11, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">A</span>n agent needs to read your calendar, so you hand it your credentials. It works immediately, which is the problem. That agent can now do everything you can do — send email, delete files, approve expenses — and every action it takes appears in the audit log as you.\n\nWhen something goes wrong, and eventually it does, there is no way to tell what you did from what the agent did on your behalf while following instructions embedded in a document it was asked to summarise.\n\n## What changed in 2026\n\n- **Non-human identity became its own category.** Security teams stopped treating agents as a variation on service accounts and started giving them distinct identity models with their own lifecycle.\n- **Delegation chains got explicit.** The pattern of \"this agent is acting for this user, under this authorisation, for this task\" moved into tooling rather than living in application logic.\n- **Prompt injection made credential scope urgent.** Once it was clear that an attacker who controls any part of the context can influence tool calls, over-permissioned agents stopped being a theoretical risk.\n- **Short-lived credentials became the default recommendation.** Long-lived API keys held by agents are now treated the way hardcoded passwords have been for years.\n\n## Why borrowed credentials fail\n\n| | Agent uses your credentials | Agent has its own identity |\n| --- | --- | --- |\n| Audit log | Shows you | Shows the agent, and who authorised it |\n| Permissions | Everything you can do | Only what the task needs |\n| Revocation | Revoke your access too | Revoke the agent alone |\n| Blast radius | Your entire account | The scoped permission set |\n| Compromise | Indistinguishable from you | Contained and attributable |\n| Rate limits | Shared with your own use | Separate and observable |\n\nThe audit row is the one that matters most and gets noticed last. Security investigations depend on being able to reconstruct who did what. An agent operating as you destroys that capability permanently — not degraded, destroyed, because the records genuinely do not contain the information.\n\n## Scoping to the task\n\nThe instinct is to scope permissions to the user: the agent acts for Alice, so it gets Alice's permissions. That is better than a shared admin key and still far too broad.\n\nScope to the *task* instead. An agent summarising invoices needs read access to invoices. It does not need write access, does not need other document types, and certainly does not need payment capability — even though Alice has all three.\n\nThis matters because agents are manipulable in ways ordinary software is not. A traditional integration does what its code says. An agent does what its context suggests, and its context includes documents, search results, and tool outputs that may be attacker-controlled. The realistic threat model is that some fraction of agent actions will be influenced by content you did not write, and permission scope is what bounds the damage when that happens. [Prompt injection defense](/blog/prompt-injection-defense-guide-2026) covers the attack side; scoping is the mitigation that works even when the defence does not.\n\nPractically: one identity per agent role rather than per agent instance, permissions granted per tool rather than per system, and read-only by default with writes as a deliberate exception. [AI agent permissions](/blog/ai-agent-permissions-guide-2026) goes deeper on the permission model itself.\n\n## Delegation, and keeping the human visible\n\nAn agent rarely acts on its own behalf. It acts because someone asked it to, and that chain needs to survive into the logs.\n\nA well-formed record answers three questions: which agent acted, which human authorised it, and under what task scope. Drop any one and accountability breaks. Just the agent tells you a machine did something with no idea why. Just the human is the borrowed-credential problem again.\n\nThis gets harder with subagents, where an orchestrator delegates to workers that delegate further. The authorising human must propagate down the chain, and the scope should narrow rather than widen at each hop — a subagent inheriting *more* permission than its parent is a bug, and it happens when each level authenticates independently rather than passing a constrained credential down.\n\nShort-lived credentials do a lot of work here. A token valid for the duration of one task, scoped to that task, is dramatically less useful to an attacker than a key that works indefinitely. When an injection succeeds — and some will — the difference between a five-minute token and a permanent key is the difference between an incident and a breach.\n\n## Common mistakes\n\n- **Sharing one agent identity across users.** Every action attributes to the agent with no way to reconstruct who triggered it.\n- **Putting credentials in the prompt or a tool description.** Anything in the context window is reachable by whatever else is in the context window.\n- **Granting the union of everything any agent might need.** Permissions accumulate and nothing gets removed.\n- **No expiry on agent credentials.** A leaked permanent key is permanent.\n- **Logging the agent but not the authorising human.** Half a record is not an audit trail.\n- **Letting subagents authenticate independently.** Scope should narrow down the chain, not reset.\n- **Treating a read-only agent as harmless.** Reading is how data exfiltration works; scope reads too.\n\n## FAQ\n\n**Is a service account good enough?**\nIt is a reasonable starting point and usually too coarse. Service accounts were designed for deterministic software with fixed behaviour. Agents need the delegation context — which human, which task — that a plain service account does not carry.\n\n**How do I handle an agent that genuinely needs broad access?**\nPush the approval to a human for the sensitive subset. An agent that can draft a refund and requires confirmation to issue it has a very different risk profile from one that can issue it directly, and the friction is usually acceptable — [human-in-the-loop agents](/blog/human-in-the-loop-agents-2026) covers where to place those gates.\n\n**What about agents calling third-party APIs?**\nSame principles, harder execution, because you are constrained by what that provider's auth model supports. Where scoped tokens are available, use them. Where only a full-access key exists, keep it server-side behind a tool you control rather than handing it to the agent.\n\n**Does this apply to a single-user local agent?**\nLess urgently, and the audit argument still holds. A local coding agent with your full credentials can do anything you can, and its context includes files and web content you did not write.\n\n## Where to go next\n\nFor the attack this permission model defends against, read [prompt injection defense](/blog/prompt-injection-defense-guide-2026). For the permission model itself, [AI agent permissions](/blog/ai-agent-permissions-guide-2026), and for the traces that make delegation chains reconstructable, [AI agent observability](/blog/ai-agent-observability-2026).","hue":204,"metaTitle":"Agent Identity and Auth: Who Is the Machine?","metaDescription":"Why AI agents need their own identities rather than borrowed user credentials, how to scope permissions to tasks, and what to log for real accountability.","keywords":["agent identity","ai agent authentication","agent credentials","service account for agents","delegated authorization ai","agent permission scoping","non human identity","ai agent security 2026"],"tldr":["**Give the agent its own identity, not a copy of yours** — shared credentials make the audit log useless and the blast radius unbounded.","**Scope permissions to the task, not the user** — an agent that summarises invoices does not need the ability to issue refunds.","**Short-lived credentials beat long-lived keys** — a token that expires in minutes limits what a prompt injection can do with it.","**Log the human behind the agent** — every action needs both the acting identity and the person who authorised it, or accountability disappears.","**Skip:** embedding API keys in prompts or tool descriptions. Anything in the context window is reachable by an attacker who controls part of that context."],"readTime":"5 min read","wordCount":1122},"related":[{"slug":"ai-agent-permissions-guide-2026","title":"AI Agent Permissions: Deciding What It May Do Alone","excerpt":"Autonomy is a permissions problem, not a model problem. Here is how to design approval tiers, scope credentials, and set the boundary between act and ask.","category":"ai","date":"August 18, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":202},{"slug":"what-is-authentication-vs-authorization-2026","title":"Authentication vs authorization in 2026: who you are vs what you can do","excerpt":"Authentication proves who you are; authorization decides what you are allowed to do. This guide explains the difference, how they work together, and why mixing them up causes security holes.","category":"code","date":"May 25, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":0},{"slug":"human-in-the-loop-agents-2026","title":"Human-in-the-Loop Agents: Where to Put the Approval Gate","excerpt":"Approve everything and the agent is a slow autocomplete. Approve nothing and you have handed irreversible actions to a system that can be talked into things.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":197}],"sameCategory":[{"slug":"agent-cost-attribution-2026","title":"Agent Cost Attribution: Finding Where the Tokens Went","excerpt":"A single monthly API bill tells you that agents are expensive. It does not tell you which feature, which customer, or which retry loop is responsible. That gap is fixable.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":220},{"slug":"human-in-the-loop-agents-2026","title":"Human-in-the-Loop Agents: Where to Put the Approval Gate","excerpt":"Approve everything and the agent is a slow autocomplete. Approve nothing and you have handed irreversible actions to a system that can be talked into things.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":197},{"slug":"reasoning-effort-controls-2026","title":"Reasoning Effort Controls: Tuning How Hard a Model Thinks","excerpt":"Fixed thinking budgets gave way to effort levels, and the default is rarely the right setting. Here is how the dial behaves and where each level actually belongs.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":210},{"slug":"retrieval-metrics-explained-2026","title":"Retrieval Metrics: Measuring the Half of RAG That Fails","excerpt":"When a RAG system answers badly, the retrieval usually failed before the model ever spoke. Measuring generation quality alone hides that entirely.","category":"ai","date":"August 19, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":215}],"newer":{"slug":"wifi-8-explained-2026","title":"Wi-Fi 8 Explained: Reliability Instead of Peak Speed","excerpt":"Wi-Fi 8 is the first generation that does not raise the headline speed number. Here is what it optimizes instead, when hardware arrives, and whether it matters at home.","category":"tech","date":"August 12, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":232},"older":{"slug":"backpressure-explained-2026","title":"Backpressure Explained: Failing Before You Fall Over","excerpt":"A system without backpressure accepts work until it collapses. Here is how to signal overload, where to put queues, and why unbounded buffering is the core mistake.","category":"code","date":"August 11, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":265}}