Delegated authority, running locally: Give an agent on your machine an identity you can trust

Part 3 of our agent-identity series: a reference architecture showing how a locally running AI agent, like the coding assistant in your editor or the copilot in your browser, can borrow a human's authority in a scoped, short-lived, auditable way, anchored in an app the user already trusts. The second post in this series gave us a way to reason about agent identity: a 3x2 taxonomy along two axes. The Authority Model describes the authority under which the agent operates: delegated (acting for a specific human), bounded (operating within a fixed grant), or autonomous (making unsupervised decisions across tasks). Deployment refers to whether the agent deployed locally or remotely. Each combination of authority model and deployment has its own set of requirements, worthy of a blog post describing the architecture. This is the first of those deep dives, and it covers the most common cell: delegated authority, running locally. It's the pattern behind the IDE coding assistant, the browser copilot, and the desktop AI helper. What follows is a reference architecture, not a new protocol. It defines no new tokens or wire formats. Its contribution is a coherent composition of existing and emerging open standards, plus a few constraints layered on top. It's also aspirational. This is the direction we believe the industry should move in, not a claim that anyone, including 1Password, has shipped it end-to-end. The architecture answers one narrow, hard question. How do you give an unattestable local process a trustworthy, scoped, short-lived, auditable identity without a long-lived agent key on disk? And it has to do that while satisfying the three requirements the last post set out, which cut across every architecture in this series and don't relax just because the agent is convenient: Eliminate long-lived credentials Produce attribution-complete audit records, every action traceable to a specific human and reconstructable from logs alone Maintain strict development/production trust boundaries While some patterns exist for these requirements in cloud-based environments, meeting them on a developer’s laptop is a harder challenge and requires the use of emerging protocols. What "delegated" and "local" mean here Picture the moment a coding assistant is halfway through a task on a developer's laptop and decides it needs a production database credential to finish. The resource on the other end (the database) has to answer four questions before acting: which agent is this, who is it acting for, is it allowed to do this right now, and can we prove later that it happened? Delegated means the agent acts on behalf of a named human, the Subject, who remains the authorizing principal. Every action must be traceable back to that specific human. An agent that logs actions under a shared service account has failed delegation outright. If your audit trail points at "the assistant" without identifying the human, you have an anonymous proxy, not a delegated identity. Local means the agent runs on the end-user's device or inside a browser origin, under the user's OS account. This is a prevalent agent pattern in use today, which is why it deserves the first deep dive. In the scenario above, the relationship between this specific agent acting for this specific person right now is what the architecture has to make cryptographically legible to the resource server. The local trust boundary A locally running agent lives in a weaker environment than a cloud workload, in three ways. Firstly, it isn't hardware-attested by default. A cloud platform can lean on a trusted execution environment (TEE) to assert "this exact binary, unmodified, is what's running." A typical consumer laptop offers no such guarantee. There’s no ambient proof of which process is asking, so no hardware-rooted attestation can be assumed. Second, secrets sit in a shared blast radius. Tokens and keys held by a local process live in memory that other same-user processes can read. Local credential theft, process injection, and memory scraping are well-known attacker techniques, so any secret the agent holds is accessible to the rest of the user’s session. Browser agents inherit an extra layer of exposure from origin-bound credential scoping, malicious extensions, service-worker interception, and DOM-based prompt injection, on top of everything above. However, there is a real advantage here: the human is physically present. A local delegated agent is almost always launched interactively by a user at the keyboard. This makes phishing-resistant human authentication, per-task consent, step-up re-authentication, things that are out of reach for unattended remote agents, practical. The present human is the strongest primitive the local environment offers, and the architecture leverages that. A composition of standards, not a new protocol To keep the pieces organized, the architecture borrows a seven-function model of agent identity from a NIST concept paper: Identification,

Extras afișat conform termenilor RSS ai publicației · 200 cuvinte · textul integral și figurile sunt pe site-ul publicației