Problems/02

Give agents capability without giving them unlimited authority.

An agent that can read a claim and an agent that can transfer money look identical from the outside. obstruo bounds what each one may do at the moment it tries, per agent identity, per tool, per action.

The problemAgent authority drift

Agent authority drift happens when agents gradually receive more models, tools and write actions than their original risk assessment allowed.

Inspect an agent authority record All problems
Four symptoms

You can recognise the drift before it produces an incident

01
One MCP server exposes read and delete

The agent was approved for lookups, and the same endpoint also carries the irreversible actions.

02
Permissions live in application code

Narrowing what an agent may do requires a release, so nobody narrows anything.

03
The agent has no unambiguous owner

It keeps running after the team that built it moved on, with authority nobody is accountable for.

04
Only actions taken are recorded, not attempts blocked

Drift looks like nothing happened, because refusals leave no trace anywhere.

The obstruo response

Six controls that turn authority into a record

Identity per agent

Policy binds to the agent behind the key, so one key behaves differently per agent.

Action-level permissions

Permitted models, tools and actions change in policy, without a deploy.

Read and write separated

A server that offers both is split at the action, not trusted as a whole.

Registered servers only

An unregistered MCP server is unreachable, per agent, and the attempt is refused in path.

Tool response redaction

What a tool returns passes the same redaction standard as a prompt before it re-enters context.

Blocked-attempt evidence

Every refusal is recorded with the agent, the argument schema and the policy behind it.

Where it becomes visible

Nobody discovers this problem in a planning meeting

A tool is added

An agent gets a new MCP server in a sprint, and its risk rating never moves.

An irreversible action

The agent writes, transfers or orders something a reviewer assumed it could not.

A team self-registers a server

Security learns about the integration after traffic is already flowing.

A model is upgraded

New capability widens what the same prompt can accomplish.

Incident review

Nobody can show which permissions were active when it happened.

The owner moves on

The agent keeps running with authority nobody is accountable for.

What it costs

The bill arrives as delay, not as an incident

01Launches get blocked

Security refuses by default, because scope cannot be bounded.

02Incidents have no owner

The action is real, the accountability is not.

03Every team builds its own guardrails

Bespoke checks per agent, inconsistent and untested.

04Approved scope is unknown

The approval covered a smaller agent than the one now running.

05Narrowing permissions needs a deploy

So permissions stay wide, because tightening them is expensive.

Why the usual tooling does not close it

The gap

How obstruo closes it

The control

IAM governs people and services, not agent identities.
Policy binds to the agent identity behind the key, so one key behaves differently per agent.
Permissions live in application code, so any change needs a release.
The permitted set of models, tools and actions changes in policy, without a deploy.
Prompt-level restrictions are instructions, not controls.
Every tool call is authorised in the request path, or refused.
Tool servers register themselves, and the register drifts.
Only registered MCP servers are reachable, per agent. Unregistered ones are refused.
Denied attempts are invisible, so drift looks like nothing happened.
Every refusal is recorded with the agent, the argument schema and the policy behind it.
The evidence artefact

What the agent may do, who approved it, and what it tried anyway.

This is the shape of the record obstruo produces. It is the same artefact a reviewer, an auditor and an enterprise buyer each ask for, and it exists before they ask.

Append-only Owner named Exportable
Agent authority record HIGH RISK
Agentclaims-triage
Accountable ownerR. Nowak, claims platform
Risk ratinghigh, reviewed 2026-06-02
Approved modelsobstruo-chat-eu, obstruo-reasoning
Approved scope2 of 11 tools, reads only
claims.record.readallowed
crm.contact.readallowed, redacted
payments.transferdenied
place_orderdenied
unregistered MCP serverrefused in path
AUTHORITY HISTORY
v14 policy, 2026-06-02, scope narrowed, apr_2291 2026-07-09, widening requested, refused, no approval on file
Authority is a record, not a code path. Every change and every refusal is attributable to a person.
The other three

They arrive together, and the same controls answer them

01
AI evidence debt
Read the problem page
03
Policy deployment gap
Read the problem page
04
Live processor blindness
Read the problem page

Your AI. Your data. Your control.

Name one agent running in production. We will show the record that bounds it and the refusals it would produce.

Map one agent's authority See pricing