Architecture Is the Safety Boundary
🎯 Hook
The first question about a coding agent is usually:
Which model should we use?
Wrong first question.
Ask these instead:
- What can it read?
- What can it change?
- Which credentials can it use?
- Which untrusted content can steer it?
- What happens if it is confidently wrong?
The model writes tokens. The architecture decides whether those tokens are a draft for review or a production incident.
🔥 Hot Take
💬 My take: “Keep a human in the loop” is not an architecture. It is a slogan until you define the boundary. A human who reviews a 2,000-line agent diff after it has already read secrets, installed dependencies, and pushed to a branch is not meaningfully in control. The real work is deciding what the agent is allowed to do before it starts, then making those limits enforceable outside the model.
This is where Staff-level judgment meets AI security. The valuable engineer is not the person who types fastest or prompts most cleverly. It is the person who can turn ambiguity into constraints, constraints into permissions, and permissions into a workflow with a known blast radius.
📰 Two Videos, One Architectural Lesson
1. How New Staff Engineers Build Judgment Without Years — Mallika Rao
TL;DR: Rao's argument is that AI has not removed engineering complexity; it has shifted it. Implementation becomes cheaper, while Staff+ work expands around decision quality, second-order effects, coordination, mentoring, and making ambiguity legible. Her working definition of judgment is “rehearsing multiple futures” before committing to one.
My take: This is the part many AI-adoption plans skip. An agent can give you three plausible implementations. It cannot know which trade-off is right for your team, production constraints, users, incident history, and roadmap. That is not a prompting problem. It is a framing and ownership problem.
Before asking an agent to execute, a human should decide:
Outcome → what success means
Constraints → security, latency, compatibility, cost, ownership
Alternatives → at least two plausible paths and their risks
Evidence → tests, checks, metrics, rollout and rollback criteria
Authority → what the agent may do without another approval
That is architecture. The implementation comes after it.
2. Claude Is Your Insider Threat Now — Dan Tentler
TL;DR: Tentler uses an intentionally alarmist title, but his serious point holds: the risky part of an AI agent is usually not the model itself. It is the surrounding “layer cake” of extensions, skills, local files, persistent memory, CI workflows, package supply chain, cloud identity, and automatic tool calls.
My take: Replace “Claude” with any agent and the point becomes useful. An LLM with broad access behaves like an untrusted workload with credentials. If it can read a repository, consume an attacker-controlled issue or document, install a package, access secrets, and push a deployment, prompt injection is only one possible trigger. The architectural mistake is ambient authority.
The talk includes incident counts and absolute claims that should be treated as the speaker's claims unless independently verified. Its containment recommendations, however, align with OWASP guidance on prompt injection, excessive agency, and keeping authorization outside the LLM.
🔗 The Thread Between Them
Rao asks: who owns the decision?
Tentler asks: what can the system do if the decision is wrong or manipulated?
Together, they describe the same engineering boundary:
| Layer | Human owns | Agent may do |
|---|---|---|
| Problem framing | outcome, constraints, trade-offs, non-goals | surface assumptions and options |
| Design | boundaries, data ownership, authority model, rollout strategy | draft alternatives and implementation plan |
| Execution | permission scope and approval rules | edit a mounted worktree; run explicitly allowed checks |
| Verification | acceptance decision and risk evaluation | run tests, linting, static checks, produce evidence |
| Promotion | merge, publish, deploy, irreversible changes | prepare artifacts; never self-authorize high-impact actions |
This is not “slowing agents down.” It is what makes agent speed usable.
🧱 A Minimal Safe Agent Architecture
Untrusted inputs
(repo, issue, docs, web, package metadata)
│
▼
Agent sandbox
- disposable runtime
- minimal mounted worktree
- no ambient secrets
- scoped tool permissions
│
▼
Deterministic controls
- tests / lint / policy checks
- dependency and CI checks
- audit trail
│
▼
Human approval
- commits, publishing, deploys
- credential use, destructive actions
- business-risk decisions
Three design rules sit underneath it:
- Least privilege: give the agent the smallest set of tools, files, network access, and credentials required for the current task.
- No security by prompt: authorization, tenant boundaries, and destructive-action safeguards must be enforced by deterministic systems—not “please do not…” instructions in a system prompt.
- Human approval at the irreversible edge: a human does not need to approve every local edit, but must control actions that create material security, business, or production risk.
OWASP recommends this same posture: restrict LLM privileges, separate untrusted external content, and require human approval for high-risk actions. It explicitly warns against delegating authorization bounds to the model.
💡 Dev Tip of the Week
For every agent tool your team adopts, write a one-page Agent Authority Contract before enabling broad access:
## Agent Authority Contract
Purpose: What problem is this agent allowed to solve?
Readable data: Which repositories, folders, services, and documents?
Writable data: Which worktrees, branches, tickets, or artifacts?
Allowed tools: Which commands and network destinations?
Forbidden authority: Secrets, production credentials, publishing, deletion, merges.
Approval gates: Exactly which actions need named human approval?
Evidence: Which tests, policy checks, and logs are required?
Rollback: How do we undo its highest-impact allowed action?
If the answers are vague, the tool is not ready for production access. You do not need an enterprise platform to start. You need explicit boundaries.
🤔 Community Question
❓ In your team, what can a coding agent do without asking again—and could you show that boundary in a diagram or policy, rather than just describing it?
📌 What I’m Learning / Building
I am treating agent adoption as an architecture decision, not a developer-productivity toggle. The useful pattern is simple: humans own framing and authority; agents execute within a deliberately small blast radius; deterministic systems verify what can be verified; humans approve the irreversible edge.
That leaves room for real speed without pretending that fast execution is the same thing as sound engineering.