AI agents: define the approval contract before granting autonomy
The agent security debate calls for a concrete architecture decision: which changes may an agent execute without approval?
Content produced with AI assistance for Thiago Silva’s website. Independent editorial analysis; it does not represent clients or employers.
The news behind this analysis
On September 2, AWS published an analysis of agent security, highlighting identity and incident response. This is vendor guidance, not the announcement of a new product.
Original source ↗From market news to an architecture decision
The editorial proposal is to turn autonomy into a verifiable contract. Before connecting an agent to a write-capable tool, document the permitted resource, change type, impact limit and approval condition. Engineering and the business process owner should both be able to understand this specification.
Consider an agent preparing a firewall change. Producing a proposal, validating its syntax and executing the change are three different permissions. Approving the proposal text should not authorize a later execution with modified parameters. The execution system must check that the action exactly matches what was approved.
A test before production
Create an exercise with an approved request and change a parameter after approval. Execution should be refused. Repeat with an expired approval and with an attempt to apply the same authorization to another resource. Record the results as control evidence without using real customer data.
Another useful test is to interrupt communication with the approval service. The expected behavior needs to be explicit: queue, reject or escalate. Leaving that choice implicit transfers a risk decision to an implementation detail.
What to bring to the next meeting
Select a single low-impact workflow for the pilot. Ask the team for a list of operations, their owners and the evidence needed to demonstrate that an approval was respected. The expected outcome is not an AI presentation: it is a small set of acceptance criteria that can be tested before access expands.
These are editorial recommendations, not validation of any particular product or environment. The AWS publication is a starting point for discussion; implementation decisions require assessment of local context and risks.