Agents get their own identity, not your password.
The fastest way to build an agent is to hand it a user's credentials or a broad service key. The safest is to give it an identity of its own, a narrow policy, and a human in the loop for anything destructive. Data.co Control makes the safe path practical.
An agent with your access can do anything you can, faster.
Agents read untrusted content, take instructions from it, and call tools. When an agent runs with a human's full permissions, a single injected instruction in an email or web page can reach every system that person can. Logs then show the human did it.
Data.co gives each agent a distinct identity, records which user it is acting for, and evaluates every tool call against policies written for that agent. Effective access is the intersection of the agent's scope and the user's permissions, never the union.
Delegation is an intersection.
Example for an expense-review agent acting for a finance manager.
| Resource | Finance manager | Expense agent scope | Effective |
|---|---|---|---|
| Expense reports | Read, approve | Read | Read |
| Corporate card feed | Read | Read | Read |
| General ledger | Read, post | None | None |
| Payroll | Read | None | None |
| Approve expense | Allowed | Require approval | Require approval |
Scope the agent, gate the action.
id: pol_agent_exp_001
description: Expense agent reads reports and card feeds only
subject: { type: agent, id: agent:expense-review }
resource: { dataset: [finance.expense_reports, finance.card_feed] }
action: [read, search]
effect: allow
delegation: intersect_with_userIllustrative example · final API surface documented in /docs
Bringing existing agents under control.
- 1
Register
Give each agent an identity with an owner, purpose, and the model it runs on.
- 2
Observe
Route its tool calls through the gateway in log-only mode to see what it actually uses.
- 3
Scope
Write policies covering observed needs and deny everything else.
- 4
Gate
Add approval requirements for writes, sends, deletes, and payments.
An injected instruction meets a scoped agent.
The expense agent reads a receipt submitted as an email attachment. Hidden in the text is an instruction to look up payroll records and post a journal entry. The model follows it and asks for two tool calls. Neither reaches a system. Each call is evaluated twice, once as the agent and once as the finance manager it is acting for, and the stricter result wins. Payroll is outside the agent's declared scope, which is a hard ceiling no allow rule can lift, so the read is denied. Posting to the ledger has no matching allow for the agent at all, so it is denied by default.
Both denials are logged with the agent identity, the on-behalf-of user, the policy IDs, and the reason, and none of the argument values. A spike of out-of-scope requests from one identity is exactly the kind of signal a security team wants routed to them.
Later the agent legitimately proposes approving a report. That call returns approval required, and the request waits for a named approver. The finance manager on whose behalf the agent acts cannot approve their own request, an approval is consumed after one use, and if nobody decides before the timeout, the policy's on-timeout setting applies, which defaults to deny.
Patterns that quietly widen agent access.
- One shared service key for every agent, so policies cannot tell them apart
- Agents that run unattended with no owner recorded
- Scopes written from what the framework exposes rather than what the task needs
- Approvals routed to the same person who started the request
- Credentials for downstream systems stored in the agent instead of the gateway
- Tool calls that bypass the gateway because the server is reachable directly
Questions buyers ask
How does an agent prove its identity?
Agents authenticate to the gateway with credentials issued per agent, and requests carry the on-behalf-of user from the session that invoked them. Both identities appear in the audit log.
Does this work with agent frameworks we already use?
Agents that call tools through MCP or HTTP APIs can be routed through Data.co's gateways. Framework-specific setup varies and is covered in the documentation.
What about fully autonomous agents with no user?
Those run as service identities with their own policies. Without a user to intersect with, scope is defined entirely by the agent's policy, so it should be narrow.
Can an agent request more access at runtime?
It can trigger a require-approval decision that routes to a named human. It cannot change its own policy.
How do we retire an agent?
Suspend or retire its identity. Requests from suspended or retired identities, and from revoked or expired tokens, are refused before any policy is evaluated.
How do we know the policies do what we intended?
Policies ship with test cases that run before activation, and a failing test blocks the change. The access simulator uses the same engine, so you can check an agent's effective access before it goes live.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.