Most AI agent demos start with a generous assumption: give the agent an API key, wire up a few tools, and let it get to work.
That is fine for a prototype. It is exactly the wrong shape for production. If an agent can read every table, call every endpoint, and write to every destination because it holds one broad credential, you do not have an agent architecture. You have a very fast intern with root access.
[TODD: drop a specific moment here — e.g. a real system you saw at Goldman/Bridgewater where one shared credential ended up doing far more than anyone intended, or an early Datris customer call where this came up. Something with a number, a name, or a date that nobody could have invented. One paragraph, four or five sentences max. This is the single highest-leverage edit for de-AI-ing the piece.]
MCP gave agents a standard way to discover and call tools. That was a big step. But tool discovery is only one layer. The next question is access: what is the agent actually allowed to do, against which data, and with what audit trail? The cleanest place to enforce that is the credential itself.
The API key is already the boundary
Every agent request already carries an API key. It rides on every MCP call and every tool invocation. That key is the most natural place to encode what the agent can do. Almost nobody uses it that way.
Most platforms still issue one long-lived, omnipotent key per account and rely on the agent’s “good judgment” to stay in its lane. That is not a security model. That is a wish.
A better pattern: the API key itself is the capability bundle. Issue narrow keys, scoped per agent and per purpose. Sometimes per session. The server enforces what each key is allowed to do at the request boundary, before the agent ever reaches a tool or a table.
This is not a new idea. Stripe has restricted keys. GitHub has fine-grained personal access tokens. AWS scopes access keys to IAM policies. In each case, the credential carries the permissions. Agents need the same model. They need it more, because they operate without a human in the loop and at machine speed.
Roles like editor or analyst are too blunt here. Humans bring context to a role; agents do not. The unit of permission for an agent should be a capability. Read this catalog, run this job, upload to this destination. Not a job title.
What a scoped agent key looks like
In practice, you stop issuing one master key per tenant and start issuing one scoped key per agent. The key is the handle, and it carries its own capability set:
{
"key": "...",
"label": "support-rag-builder",
"capabilities": [
"pipeline:read:catalog=support",
"pipeline:create:catalog=support",
"pipeline:run:catalog=support,owner=self",
"tap:create",
"tap:run:owner=self",
"secret:read:_type=tap",
"secret:write:_type=tap",
"document:upload:collection=support_docs",
"search:vector:collection=support_docs",
"metadata:read",
"job:read",
"job:kill:owner=self",
"config:read"
],
"createdAt": "2026-05-20T14:32:00Z",
"createdBy": "admin",
"revoked": false,
"isLegacyFullAccess": false
}The agent presents that key on every request:
x-api-key: dtk_live_a7f3b9c2e4d1f6a8...The server looks up what the key is allowed to do and enforces it before any tool runs. No separate role lookup, no inherited permissions. The key is the capability.
That key can build and search a support knowledge base. It cannot dump the customer database, delete production pipelines, or publish data to an external system. The agent can ask. The server will refuse, because the key does not carry the capability.
A different agent gets a different key. A reporting agent gets read on three catalogs and nothing else. An ops agent gets job-status reads and a narrow restart permission. When something goes wrong, and something always does, you revoke that one key. Every other agent keeps working. The blast radius stops at the credential.
Narrow keys need rich feedback
There’s a trap here, and it took me a while to see it. Narrow permissions are only half the work. If the feedback is poor, agents get brittle. They retry blindly, or they escalate every issue to a human, and now you’ve just built a slower, more annoying intern.
An agent operating with a scoped key needs structured answers: did the job finish, which stage failed, was it a schema problem, a quota problem, or a permission problem? A permission denial is a different signal from a bad date format. If the platform returns “your key is not authorized for that operation,” the agent knows to stop and surface the issue. If it returns “row 4327 failed validation,” the agent knows to adjust the rule and retry. Assuming its key allows that.
The point is to let the agent fix only the classes of problems its key is authorized to fix, and escalate the rest with enough context to be useful.
MCP makes this more urgent
MCP standardizes tool access. That is good. It also means agents can discover more tools more easily. A tool list is not a security model.
The cleanest enforcement signal is the key the agent presented when it connected. The same MCP server can expose a full tool surface to one key and a narrow slice to another. Two agents connecting through different scoped keys should see different capabilities, and any attempt to invoke a tool outside the key’s scope should be denied at the server, not at the model.
That changes the deployment story. You stop running one MCP server with one shared key. You run a server that understands scoped credentials, capability grants, tenant boundaries, audit logs, and revocation.
What to look for in an agent-ready platform
If you are evaluating whether your stack is ready for agents, ask practical questions:
- Can I issue a separate API key per agent, with different capabilities on each?
- Can I distinguish read, write, create, run, search, and delete permissions on a single key?
- Can I scope a key to one catalog or destination without exposing everything else?
- Can I trace every operation back to the specific key, agent, and session that requested it?
- Can I revoke one key without rotating credentials across half the stack?
If the answer is mostly no, the agent is not operating inside a controlled system. It is operating around one.
At Datris, this is the direction we’re building toward. When API keys are enabled on the platform, every agent authenticates with a scoped key that carries exactly the capabilities it needs, and nothing else. That same key is what the server checks against on every call, what audit logs record, and what you kill when an agent goes sideways.
The goal is not to make agents weak. It’s to let them do the right things, safely and repeatedly, with a credential that’s honest about what they’re allowed to touch.
If you are building agents that need to work with real data, take a look at the Datris Platform OSS repo or visit datris.ai. The credential layer is becoming just as important as the model layer.
Todd Fearn is the founder of Datris.ai and has been building AI solutions and data infrastructure for financial services for 25+ years, including at Goldman Sachs, Bridgewater Associates, Deutsche Bank, Freddie Mac and others.