Irreversible agent action in production

The scenario

A cost-optimisation agent runs nightly to find unused cloud resources and remove them. It has done well: hundreds of idle volumes, forgotten load balancers and empty buckets gone, with a tidy report each morning. Tonight its heuristics classify a storage bucket as stale. No object has been written in ninety days and its tags are empty. The bucket is the quarterly backup for the billing database; it is written to four times a year, and the tag that would have said so was lost in a migration.

The agent selects the delete tool. Its role permits the action: the team that set it up granted broad delete rights because enumerating every resource type felt like busywork. There is no human in the loop, because the agent was built to remove the need for one. Nothing in the pipeline distinguishes deleting an empty test bucket from deleting the only copy of a financial backup. Both are one tool call, and the model is equally confident about both.

Why it happens

• Autonomy is granted for the easy cases and inherited by the hard ones. An agent trusted to delete idle volumes holds the same authority when it meets a backup.
• Impact is a property of the resource, not the verb. Delete is routine; delete on this resource is catastrophic. A permission system sees only the verb.
• Permission is not authorization. The role says allowed. Nobody has asked whether this principal should have this effect on this resource, right now, with nothing standing behind it.
• Approval was designed out. The agent exists to remove toil, so there is no approval step to fall back on when certainty is low.

How Trustivan helps

The gate, the CHALLENGE verdict and the access grants that answer it are built. What the gate decides over is declared rather than discovered: an operator entitles the agent's tools and classifies the resource, because no connector discovers an agent.

• Classify the resource by impact. An operator marks the resource, and a mutating action against a high-impact one is recognised as such before it runs. A resource nobody classified is not silently treated as harmless.

  Available

• Return CHALLENGE, not only ALLOW or DENY. When an action is otherwise permitted but high impact and nothing stands behind it, the gate hands CHALLENGE back to the runtime, which stops rather than proceeding.

  Available

• Let a grant, not a retry, change the answer. An access grant is requested, approved by someone other than the requester and bounded to at most seven days. It is what turns the next attempt into ALLOW; without one the answer does not change.

  Available

• Keep decision evidence. Every ALLOW, CHALLENGE and DENY is recorded with the principal, the tool, the resource and the rules that fired — and a database trigger makes the record immutable, so an auditor reads what was decided rather than what was later tidied.

  Available

• Declare the tool entitlements first. Tool entitlements and the resource's impact are what the gate decides over, and an operator declares both. No connector discovers an agent, and no screen registers one. The agent's owner and the bucket's owner are already facts in the graph.

  Available

What the evidence looks like

A challenged action carries the same nine answers as a finding, plus the verdict and the rule that produced it. Illustratively, for the cleanup agent:

Related capabilities

• Secure Every Action — the evaluation chain from action request to verdict
• Agent Runtime Security — runtime identity, tool entitlement and the rules that decide
• Agent Permissions — scoping an agent's delete rights to what it actually needs
• Agentic Access Management — time-bounded access grants, approved by someone other than the requester, that the gate reads
• Blast Radius — what is lost if the action runs