Restricting an agent to read-only views removes the runtime SQL construction it once had

The third layer is the agent-specific one. Authentication decides who is making the request, validated by OIDC or OAuth 2.0 access tokens for human-in-the-loop sessions and by mutual TLS or signed JWTs for background worker agents ^[8]. Authorization decides what that identity may do globally, through RBAC or ABAC against a specific resource or database table ^[9]. Agent scope asks something narrower: given that user U holds permission P and agent A is executing task T, which subset of P should be active during this specific tool invocation loop ^[10].

The post's description of the agent and its remedy for the agent do not fit together. The model "constructs SQL statements" at runtime from natural language input ^[2]. The database boundary restricts the agent to read-only views or parameterized stored procedures mapped to tenant-specific partitions ^[15]. Those two cannot both be true of the same tool: a pre-declared view or procedure is exactly the set of query shapes someone wrote down in advance ^[22]. Someone has to author those views and procedures ahead of time. That is the work a reviewed code path was already doing.

Cloud access gets bounded by temporary IAM session policies sized to the expected lifetime of the task loop, with 15 minutes given as a maximum ^[16]. A day holds 96 such windows ^[19]. Compare that with the naive setup the post describes, which is a broad database connection string, an unrestricted API token, or a cloud service principal with administrative permissions across several projects ^[12]. When a prompt injection payload changes the model's objective, the post puts the blast radius at the entire infrastructure ^[13]. The 15-minute ceiling caps that exposure at one task loop.

The credential broker is the part I would copy first. Ephemeral tokens are injected directly into the tool execution boundary, and raw secrets never enter the model context window ^[17]. Tool output is where that breaks down. A tool that returns its own bearer token in a response body, an error string, or a signed URL puts the secret back into context, and the broker has no way to observe it. Models already fail to evaluate the secondary and tertiary side effects of asynchronous multi-step chains, per the post ^[5], so nothing in the loop will flag the leak either.

One session can traverse identity providers, CRM systems, cloud object stores, and internal microservices ^[4]. The scope question has to be answered at each invocation. This is an architecture argument: the post does not cite a deployment, an incident, or a measurement ^[21]. I think its central equivalence holds. Without dedicated architectural boundaries, the post writes, giving an autonomous system access to enterprise tools is "functionally equivalent to granting arbitrary remote code execution to an untrusted user" ^[6]. I agree in the narrow sense that the prompt is untrusted input and the tool list is the syscall table.