AI agent permissions: why ours asks first

Every conversation about deploying an AI agent inside a regulated firm eventually arrives at the same sentence, usually said quietly: "So this thing has credentials and its own initiative." That sentence deserves a better answer than reassurance. Software that decides for itself what to do next is a genuinely new kind of actor inside a controlled environment, and the controls that worked for deterministic software — service accounts, static role assignments, quarterly access reviews — assume an actor that does the same thing every day. An agent doesn't. The whole point of an agent is that you did not enumerate its actions in advance.

So the permission question is not "what can the model do" — models can emit text, nothing more. It is: which capabilities has your organisation granted this session, who granted them, what happens when the agent reaches the edge of them, and can you prove all three afterwards. This article is how DataQube answers each part.

Capability is a grant, not a default

In DataQube, an agent session starts with nothing. Every capability it holds — reading a particular warehouse, opening a document store, running a workflow, writing a draft file in its own workspace — exists because a specific grant says so. Grants are scoped to people and workspaces: your organisation sets a baseline for a workspace, the workspace can narrow it, and a person's session holds the intersection of what the workspace allows and what that person is individually entitled to. An agent working for an analyst can never do more than that analyst; there is no system identity with superpowers standing behind the curtain.

Three properties make this a control system rather than a settings page:

• Revocation wins immediately. Remove a grant, and the very next run is missing that capability. There is no cached ambient access to age out.
• A denial beats any allow. Information barriers are expressed as explicit denials, and an explicit denial overrides every permission that would otherwise apply. There is no combination of grants that argues around a barrier.
• Delegated work inherits the ceiling. A scheduled workflow runs with the access its owner holds — scheduling something never widens what it may touch. If the owner loses a grant on Tuesday, Wednesday's run is narrower, automatically.

The rejected design here is the one most tools ship: an "autonomy" slider — low, medium, YOLO — that sets how much the agent may do everywhere, for everyone. We think that abstraction cannot survive contact with an enterprise. Autonomy is not a temperament; it is a per-capability, per-person, per-workspace decision, and pretending otherwise just moves the real decisions into a place nobody can audit.

The agent stops and asks

Grants handle the capabilities you decided about in advance. The more interesting moments are the ones you didn't.

When a DataQube agent reaches an action that its policy marks as sensitive — sending something outside the workspace, writing to a shared location, running an action a grant marks as ask-first — it does not guess, and it does not silently fail. It stops, mid-run, and asks a person. The question is specific: this action, these parameters, this target — not a vague "allow the agent to continue?" The person can approve once, approve for the workspace, or refuse, and the run resumes or reroutes accordingly.

Two details matter more than the headline behavior. First, the ask finds the right person. An approval that only works if the requesting analyst happens to be online is a control that fails at 6 a.m. — precisely when scheduled work runs. Asks route to whoever holds the authority to answer them, across sessions, and wait. Second, the answer becomes part of the record: who was asked, what exactly they saw, what they decided, and when. An approval is not a click that evaporates; it is an event with the same standing as the query it unblocked.

Here is what it looks like in practice. An analyst asks the agent to send a finished exposure pack to an external counterparty address. Sending outside the workspace is ask-first in her organisation, so the run pauses and the ask routes to the workspace owner: the file, the destination, the grant that requires approval. The owner approves this send only; the run resumes; the record now contains the pack, the approval, and the identity of everyone involved. Total added friction: one decision, made by the right person, once.

This is the practical resolution of the human-in-the-loop debate. A human on every action produces click-through fatigue and, within a week, a rubber stamp — a control that exists only in screenshots. A human on no actions is the sentence at the top of this article. A human exactly at the policy-defined edges, with the ask routed to the right authority and recorded — that holds up, both operationally and in front of an auditor.

Denials are records, not dead ends

Most systems treat a refused action as an error to suppress. We treat it as some of the most valuable data the platform produces.

When a session attempts something outside its grants — a source beyond an information barrier, a write it was never given, a workflow it may not run — the refusal lands in the audit log with the rule that fired, alongside every successful access. This is what your security team actually reviews: not the happy path, but the negative space around it. Who bumped into which boundary, how often, and whether the boundary held. A quarter's worth of denials is the evidence that your barriers work — or the early warning that someone keeps probing one.

It also changes the conversation with the person who was refused. A denial with a rule attached ("blocked by the research/trading barrier, set at organisation level") is something they can take to an administrator and discuss. A generic failure teaches people to work around the system; a legible one teaches them how the system works.

What administrators actually see

Controls you can't inspect are controls you have to take on faith, so the administrative view is deliberately boring: an inventory. Which tools exist at the organisation level; which workspaces carry which subset; which people hold which grants on top; which actions are marked ask-first; and the stream of asks, approvals, and denials the running system has produced. When your access review comes around, the answer to "who can the agent act as, and what may it do for them" is a page you read, not an investigation you commission.

The same inventory answers the diligence question we hear most from security teams evaluating our architecture: "what is the blast radius if a session is compromised or simply wrong?" The honest answer is: the grants of one person, in one workspace, minus every denial, with the sensitive edges gated by asks that route to someone else. That is a boundary you can reason about — and critically, one you drew, not one we shipped.

The test to run in any evaluation

If you are evaluating agent platforms, permission models are where marketing and architecture diverge fastest, and there is a short list of questions that exposes the difference. Ask to see revocation take effect — not in a policy document, in a running session. Ask what a scheduled job may do after its owner's access is reduced. Ask the vendor to show you a denial in their audit log, with the rule that produced it. And ask what happens, concretely, when the agent wants to do something sensible that nobody pre-authorised — whether it guesses, fails, or asks someone with the standing to answer.

Our answers are on the security page, stated as guarantees you can test during a pilot. If you'd rather see the asking behavior live — the agent stopping, the ask routing, the record forming — book a demo and we'll trip the boundary on purpose.