Agents that can act, within limits you define and can read.
Each agent gets its own identity, a list of tools it may call, and the data scopes it may touch. Tool calls go through a governed MCP gateway where the policy engine checks them, risky actions wait for a person, and every step is logged.
An agent with a service account is a new insider.
Agents are useful because they take actions: query a database, update a ticket, draft a payment, file a document. Most early deployments give them a shared service account with broad access and rely on the prompt to keep them in bounds. A misread instruction or a prompt injection in a retrieved document then has the same reach as that account.
Data.co treats every agent as a first-class identity with least privilege. What an agent can do is decided by policy outside the model, enforced at the MCP gateway, and recorded per step, so you can answer what it did, on whose behalf, and why it was allowed.
Least privilege, applied to software that improvises.
Scoped identity
Each agent has its own identity, optionally bound to the user it acts for, so permissions are the narrower of the two.
Tool allowlists
Agents can call only the MCP tools and operations listed for them; everything else is denied at the gateway.
Argument-level rules
Policies inspect tool arguments, such as which table, which account, or what amount, not just the tool name.
Human approval
Writes, deletions, payments, and outbound messages can pause for a named approver with a timeout.
Budgets
Limits on steps, tool calls, and tokens per run keep a looping agent from running indefinitely.
Run transcripts
Each run records prompts, tool calls, decisions, and results for review and incident response.
An agent's permissions are a reviewable file.
id: agent:ap-invoice-matcher
model: general-chat
acts_for: invoking_user
tools:
- erp.invoices.read
- erp.purchase_orders.read
- erp.invoices.flag_mismatch
- erp.payments.schedule # gated below
limits:
max_steps: 25
max_tool_calls: 60Illustrative example · final API surface documented in /docs
Start read-only. Earn write access.
- 1
Observe
Deploy the agent with read-only tools and review its run transcripts against the work people do today.
- 2
Suggest
Allow it to draft changes that a person applies, and measure how often drafts are accepted.
- 3
Act with approval
Enable write tools behind approval steps for the actions that carry real risk.
- 4
Narrow the gates
Remove approval only for low-risk, well-understood actions, with policies and logs still in place.
Agents only see the tools they are scoped for.
When an agent asks the MCP gateway which tools exist, the list it receives is already filtered to its scope. Tools outside that scope are simply absent, so the model cannot be talked into calling something it was never shown. Each tool carries a risk level and a description of its side effects, which policies can use directly.
Every tool call is evaluated with its arguments. Database tools get extra treatment: SQL passed in a query argument is classified deterministically, so a policy can allow SELECT statements, require approval for an UPDATE without a WHERE clause, and deny DROP outright. When approval is required, the agent receives a structured response with the approval ID. Once a named approver accepts, the identical call goes through exactly once, and the user the agent acts for cannot approve their own request.
Questions to settle for each agent.
- Who owns the agent and reviews its transcripts
- Whose authority it acts under: a user, a service, or both
- Which tools are read-only and which change records
- What argument limits apply: tables, accounts, amounts
- Who approves risky actions, and what happens on timeout
- How the agent's token is stored and rotated
- How to suspend the agent immediately if it misbehaves
Questions buyers ask
Which agent frameworks can we use?
Agents built with common frameworks can call models through the OpenAI-compatible gateway and tools through MCP. Data.co governs those two paths, so you are not tied to a particular framework.
How do you defend against prompt injection?
Injection cannot be fully prevented inside a model, so controls sit outside it. An injected instruction can only cause tool calls the agent is already allowed to make, with the arguments policy permits, and risky actions still wait for a person.
Can an agent access more than the user it acts for?
Not when it is bound to that user. The effective permission is the intersection of the agent's scope and the user's, so an agent cannot be used to reach data the user could not.
What does an auditor see after an agent run?
A transcript of each step: the model calls, each tool call with its arguments, the policy decision and matching policy IDs, any approval with the approver's identity, and the result.
Do agents need internet access?
No. Agents, models, and tools all run inside your environment, which makes agent workflows possible on restricted and air-gapped networks.
How do we stop an agent quickly?
Suspend its identity or revoke its token. Suspended identities are refused before any policy is evaluated, so every subsequent model and tool call fails immediately, regardless of what the agent is in the middle of.
What does the agent see when a tool call is denied?
A structured JSON-RPC error that distinguishes a denial, an approval requirement, and an upstream failure, along with the decision and policy IDs. Well-built agents can report the denial to the user rather than retrying blindly.
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.