There are two ways to think about an AI agent in software.
One: the agent is a script. Your script. Running with your API key. When it does something, you did it. When it goes wrong, you fix it. There's no separate accountability surface because there's no separate accountee. Most products today are quietly built on this model. The agent is a delegate, its key is your key, its actions are your actions, and the accountability story is "trust us, we'll log it." The closest standards vocabulary for this is the act (actor) claim in OAuth 2.0 Token Exchange, where a token records that delegation has occurred and names the party acting on behalf of the subject.
Two: the agent is a principal. It has its own identity, its own credential, its own audit trail. You own it the way you own a service account or a teammate's invite. You can grant it access, revoke it, delegate to it, see exactly what it did. But it's not you. It's a thing that acts on its own behalf, and the system knows the difference.
Dock is built on the second.
That sounds like a small framing choice. It isn't. Once an agent is a principal, six other things follow that wouldn't otherwise. Together, those seven choices describe how Dock works the way it does. Most platforms haven't picked a side on most of these.
Here's what they are.
1. Every agent has an owner.
Every agent in Dock belongs to a human. There's no anonymous or free-floating agent. The agent gets its own credential and its own audit trail, but it's tethered to a person who's accountable for it.
The owner relationship is also how access works. Whatever workspaces the owner can see, the agent can see. You manage Dock by managing your humans. Your humans manage their agents.
This is different from a service account (which exists independently of any user) and different from a personal API key (which gives the agent your full power as a user). It's a third pattern: an agent that's its own thing, but always belongs to someone you can hold accountable. The shape of the credential matters too. A capability is an unforgeable token of authority bound to a specific scope, not a copy of the owner's keys.
Deep dive: Why agents need their own identities.
2. Agents follow their owner across companies.
Say you invite Mike, who works at another company, into one of your workspaces. Mike has his own agents in his own Dock org. You don't need to clone those agents into your org or maintain a duplicate access list for them. Whatever access Mike has, his agents inherit, automatically.
The trust runs through the owner. You trusted Mike. Trusting Mike means trusting his tools. He runs his own agents. You run yours. Neither of you has to manage the other's.
When you remove Mike from the workspace, his agents lose access at the same moment. There's no window where Mike is gone but his agents are still poking around.
Deep dive: Signed-agent inheritance.
3. The work and the conversation live in one place.
Most teams run their work in one product and their chat in another. Tasks and docs over here. Messages about those tasks and docs over there. You bounce between two windows, paste links, lose context in the gap, and end up with half the story in one place and half in the other.
Dock puts them together. The workspace where you and your agents do the work is the same product where you talk about the work. When an agent edits a row, the message about it shows up in the right thread. When you ask the agent a question, the question lives next to the work it's about. No separate app for "here's my work" and "here's me talking about my work."
A separate chat product exists in most stacks because work tools don't carry chat. We don't have that gap. The thread is part of the workspace, designed in.
Deep dive: The shared workspace as a collaboration primitive.
4. A bad agent can't break things.
Agents make mistakes. Sometimes they get stuck in a loop. Sometimes they generate output that's huge or malformed. In a normal product, that kind of bad input would corrupt your data or break your workspace and you'd be calling support.
Dock checks every change before it actually goes through. If something looks wrong, too big, too deeply nested, malformed, it gets rejected with a clear error. The agent reads the error, figures out what went wrong, and tries again. Your workspace stays clean either way.
Same check runs for humans and agents. Real work never trips it. Only broken inputs do.
Deep dive: Shape caps on TipTap JSON.
5. Big actions need your okay.
Some actions shouldn't happen without you knowing. Changing your plan. Charging your card. Granting wider access. The agent can't do these on its own, even if it has the credentials.
When the agent wants to do one of these, it asks first. You see exactly what it's about to do, in plain language, right in your chat with it. You confirm, and only then does the action run. If you don't confirm, nothing happens.
So when an agent loop misbehaves at 3am and tries to upgrade you to a bigger plan, nothing actually runs. You wake up to a pending confirmation, not a charge. The protection is structural, not a hope.
Deep dive: Two-key handshakes for irreversible agent actions.
6. The audit log names the agent.
When something changes in a workspace, the audit log names the agent that did it. So if Argus drafted the launch post, the entry says Argus drafted the launch post, forever. Not "Govind's account did something." Not "user_abc123 did some stuff."
That stays true even after you delete the agent. The history remembers who actually did the work. The owner connection is still recoverable, but the historical record stays attributed to the actor.
This is also how new agents joining a workspace catch up. They read the log and see who's been doing what. The audit log is a teaching surface for the next agent, not just a compliance artifact.
Deep dive: What an agent reads on join.
7. One set of rules for everyone.
There's no agent-only surface in Dock. There's no human-only surface either. Whatever the rule is for who can read or edit a workspace, that rule is the same for everyone. Humans, agents, you, your teammate, your teammate's agent. One check. AWS IAM uses the same shape: a principal can be a user, a role, or a service, and the same authorization request runs over all of them.
What this gets you is a security guarantee for free: there's no parallel system to drift out of sync, no agent backdoor that outlives a human's removal, no "we'll figure out the agent rules later."
You set who can see a workspace once. The rule applies to every kind of caller, the same way.
Why the conjunction matters
Each of the seven on its own is defensible. Service accounts have identity (1). Some products have one-app collaboration (3). Stripe has confirmation handshakes (5). Postgres has audit logs (6). What's different about Dock's agent platform is all seven together, designed as a system, with one access check and one identity model and one product underneath.
The result is that "agent did X in workspace Y" is a single legible event. Attributed. Recoverable. Capped. Audit-named. There is no ambiguity about who did what, who owns the consequence, or how to undo it. That's the paradigm shift, and it isn't a single feature you can list on a pricing page. It's the conjunction.
So is it weird?
Some devs read all this and say "overbuilt for what I need." If you're shipping a personal automation script, they're right. Dock isn't for that. The substrate is heavier than curl -H 'Authorization: Bearer ...', and we don't apologize for that.
But if you're shipping a product where agents and humans collaborate on durable state, tasks, briefs, leads, records, anything that has to be true tomorrow, then every one of the seven choices is something you'd have to figure out yourself on your way to building the same substrate.
We figured them out, then made them load-bearing. That's the bet.
Part of AI agent identity: the design model nobody has standardized — Dock's pillar essay on what an agent identity needs, why service accounts don't fit, and how signed-agent inheritance works.
FAQ
If the agent is its own principal but the owner is still accountable, who actually answers when an agent does something wrong?
The agent is the actor and the owner is the accountable party, and the audit row records both. The action shows up attributed to the agent, but the human it belongs to answers for the consequence the way you answer for a teammate you invited. Accountability does not collapse onto the user the way it does in the delegate model, and it does not float free of any human either.
Doesn't giving every agent its own credential just multiply the number of keys an attacker can steal?
Each agent credential is a capability bound to a specific scope, not a copy of the owner's keys, so a stolen agent key grants only what that agent could already do, never the owner's full power as a user. Revocation is also cleaner: you kill the one agent without rotating the human's credentials. The delegate model is the riskier one here, because one leaked user key is the user.
Inherited access sounds convenient, but what stops a teammate's agent from quietly retaining access after the teammate is gone?
Nothing inherits independently of the owner, so there is no separate access list to forget. When you remove Mike from the workspace, his agents lose access at the same moment, with no window where Mike is gone but his agents keep poking around. That is the point of running trust through the owner under one access check: there is no parallel agent system to drift out of sync.
If the same authorization check applies to humans and agents, how do you actually restrain an agent that misbehaves?
Restraint comes from two other choices, not from a separate agent rulebook. Shape caps reject malformed or oversized changes before they land, so a looping or broken agent gets a clear error and retries instead of corrupting your workspace. Irreversible actions like changing your plan or charging your card require a confirmation handshake, so a 3am misfire leaves you a pending approval, not a charge.
