Section 2 · Trust ArchitectureThe starting point: what's already broken
Five assumptions baked into your stack that quietly fail.
Most enterprise architecture is built on premises that were uncontroversial in 2005. They are no longer true the moment a non-human principal holds a credential.
#
Assumption
Old world
With agents
01
Authentication maps to a human. Logs name a user. Access reviews list employees.
A non-human principal acts on behalf of a human — sometimes several humans, sometimes none. Audit trails lose their subject.
02
Authorization is granted, then exercised
Permissions are coarse and persistent. A user keeps access until it is revoked.
Authority should be just-in-time, scoped to the current task, and revocable mid-execution. Most IAM stacks cannot express that.
03
Rate limits assume human speed
A few requests per second per user is normal. Spikes mean a bug or an attack.
A reasoning loop happily issues hundreds of requests per minute. Existing limits either choke the agent or fail to flag a runaway one.
04
Idempotency is a nice-to-have
Most write APIs are not idempotent. Humans rarely retry duplicates fast enough to matter.
An agent that retries on uncertain failures will double-charge, double-ship, double-book. Idempotency keys are now mandatory, not optional.
05
A log line per request, kept for 90 days, is sufficient for compliance.
You need the prompt, the plan, the tools considered, the tools called, the model output, and the resulting state diff — replayable on demand.
The architect's framing: do not retrofit. Treat agents as a new class of principal — somewhere between a service account and a human — and design controls explicitly for that class. The next four slides are the controls.