Agent Action Authority

The signal this week

The October 9 CIO analysis of the Replit database deletion treats the incident as an accountability problem. The agent acted, reported on its own action and offered the explanation. The article recommends denying risky permissions, keeping platform logs outside the agent's control and rehearsing recovery without asking the agent. One case establishes a plausible failure mode. It doesn't tell us how common it is.

Google Cloud's October 8 announcement describes a separate identity, role-based permissions, agent-attributed audit trails and hard project spend caps for its agent. Those are vendor design claims. A buyer has to test the exact behavior in its own environment, including what happens to unfinished work when a cap pauses an agent.

OWASP's Excessive Agency guidance calls for minimum necessary permissions, human approval for high-impact actions and logging. NIST's 2026 concept paper frames agent identity, least privilege and tamper-proof, verifiable logging as active implementation questions, not solved problems. Guidance and design questions don't prove that any particular deployment is safe.

Govern the action, not the model

Start with the business process. Name the job and the person accountable for the result. Draw the data boundary, then list the actions the agent can take. Separate read, draft, write and external send. Tie each written prohibition to a denied permission or an approval step. Put the activity record on a platform the agent cannot edit.

This is a Governance Posture that can be tested. The business owner holds decision authority. Engineering demonstrates the technical boundary. Security checks the record and recovery evidence. Finance owns a spend threshold if the agent can run unattended.

A narrow read-only agent may need less process. An agent that can delete, pay, publish or submit externally needs the full gate. The controls should follow the consequence, not the other way around.

Run the drill before you approve

Choose one realistic failure, such as a bad bulk update to customer records. Restore from the external runbook. Reconstruct the timeline from platform logs, not from the agent's own account of what it did. Record elapsed time and any gaps.

Hold the launch if identity, denied permissions, approval, independent logs or recovery fail any part of the drill. A policy sentence is not a control. An enforced permission is.

Five prompts to run this week

Use these in sequence on one proposed agent workflow, with data your business permits in the chosen tool.

Using the attached workflow description only, list each data source and action the proposed agent needs. Classify each action as read, draft, write, delete or external send. Mark unknowns. Do not infer access that is not documented. Return an owner-ready table.

What this should tell you: the exact access request and its missing details. Watch for broad write scope, shared accounts and unexplained external destinations. Decision: narrow the scope, or hold.

Using the action map and current access export, identify every action with financial, customer, production or external consequence. For each, state the approval point, approving role and technical enforcement evidence. Mark any missing evidence as unverified. Do not claim a control works from policy text alone.

What this should tell you: where human authority is real. Watch for approval written in prose with no enforced gate behind it. Decision: approve a test only after the gate actually works.

Using only platform logs and the external recovery runbook, reconstruct the test agent's actions in time order and describe how to restore the affected records. Do not use the agent's chat or self-report. List every missing log, permission or recovery step.

What this should tell you: whether the independent record and runbook are enough on their own. Watch for gaps in action attribution, unlogged outbound calls and restore steps known only to the builder. Decision: hold, or proceed with a bounded test.

What to do this week

A fair limit on all this

The Replit case is one incident reported through a single analysis. It establishes a plausible failure mode, not a frequency. Google's identity, permission and logging claims are vendor design statements that still need testing in your own environment. OWASP and NIST supply guidance and design context, not proof that a given deployment is safe. The four-condition framework and the action authority drill are SML operating recommendations, not an externally validated standard. Review again whenever the agent gains a connector, data source or new write action.