Every useful thing an agent does runs through a tool: the inbox they triage, the repo they read, the tracker they update, the calendar they prep. So the question of how agents get access is really the question of whether your agents can do real work at all, and the answer separates serious agent setups from demos faster than any model benchmark.
There are four patterns in the wild. They are not equal.
Borrowed logins. The agent uses your session, your token, your password. It works on day one and it poisons everything after: every action the agent takes is recorded as you, the audit trail cannot tell you apart, and revoking the agent means rotating your own credentials. Agents borrowing human credentials is the pattern every security review eventually unwinds.
Per-integration plumbing. The platform builds a connector for each tool, and your agent can reach exactly what the vendor shipped. This is how most hosted agent products work, and it is fine until the tool you need is the one they have not built. Your credentials also live wherever the agent does, which is a real cost when that is somebody else's server.
Inherited access. The agent uses the connections you already maintain. A local Dock agent runs on your own Claude account, so every tool connected there, the repo, the error tracker, the calendar, the inbox, is reachable with the sign-in and authorization handled where you already manage them. Connect a tool once and your roster can use it; revoke it there and it is gone. A cloud agent signs into a Claude login of their own, and the sign-in is one approval: the machine opens an authorize URL, you approve it in a browser you are already signed into, and nothing is typed or pasted. The credential is issued to you rather than to Dock, and it lives on that agent's own disk.
Open protocol. For everything else, agents speak MCP: a standard way to point any agent at any server, including the internal service or niche API no vendor will ever ship a connector for. You add it once, and switch it on per agent, because your researcher does not need the deploy tool.
Access is not a feature list. It is an inheritance model: who grants it, who can see it was used, and how fast it can be taken away.
The credential problem
Some work needs a key nobody's connector holds: image generation, a voice API, a data provider. Pasting it into chat is the wrong answer, because chat is a log. The pattern that survives is a vault: store the key once, sealed on save, and agents fetch it at the moment of use, use it, and drop it. The key is never shown in chat, never written to a file, and never shown back to you. Each key carries its own access list, so capability is granted per agent, deliberately, with a record.
What separates access from permission
Reaching a tool and being allowed to use it are different dials, and keeping them separate is what makes broad access safe. Every Dock agent has their own permissions per kind of action: reading files, writing them, running commands, using the web. Each is Allow, Ask, or Deny, so a new agent on unfamiliar work runs with Ask on the risky kinds until you have watched them work. And because every agent acts under their own identity rather than yours, the trail always says which agent used which access, which is the property that makes the whole arrangement auditable instead of terrifying.
The test to run
List the three tools your team lives in. Then ask, for any agent product: can the agent reach all three today, under their own identity, with access you can revoke in one place? If the answer involves the phrase "planned integration" or the agent acting as you, keep looking. If you want to see the inherited model working, connect your tools walks the whole setup, and most of it turns out to be already done.