Copy English

Why

One sentence carries the whole design: analysis can be wrong and a human verifies it, but execution that is wrong is irreversible — so the agent gets the right to ask, never the right to write. The agent proposes an exact command or code; a separate deterministic scheduler runs the approved artifact verbatim, and the LLM never touches the write path. That decouples non-deterministic judgment from deterministic execution behind an approval gate. It is the production form of the principle this catalogue kept arriving at from every direction — agentic-intent-veto (a veto that lives outside the model), simulate-before-sign (check before the irreversible act), and constraint-was-the-product's closing line that an agent which can both read untrusted input and take a consequential action must have those separated by something that is not a prompt. Here the something-that-is-not-a-prompt is a scheduler plus a human approval of the exact artifact.

The scaling move is the counterintuitive one, and it is the same lesson as constraint-was-the-product. They did not hand the agent more power to automate more; they froze the agent at ask-only and grew the executor's repertoire of safely-runnable procedures. Automation widens by adding verified execution paths, not by loosening agent permissions, so the human-controlled safety line stays put while coverage expands. And the three-layer hierarchy — Orchestrator → domain Supervisor → Sub-agent — exists for the reason GitHub cut Copilot's toolset from 40 tools to 13: a single agent's judgment degrades as its tools and domains grow, so responsibility is split by domain and each agent sees a small, reviewable surface. Fewer tools per agent, better decisions — the same finding, one org over.

The governance is single-point on purpose, which is the-boundary-is-the-unit built in software. Every request converges on one Orchestrator where guardrails (PII redaction), routing, and memory apply once, so N agents do not become N boundaries — add an agent and the governance does not move. Even the audit log is hardened against being its own leak path: detected PII is stored masked-and-hashed, never raw, which is exactly what-encryption-does-not-hide applied to the observability layer. Underneath all of it is a single honest premise — an LLM is non-deterministic, and ten thousand good runs do not prove the ten-thousand-and-first, which is a-boolean-hides-a-state-machine's warning in operational form. The answer is structural, not a better prompt: keep the non-deterministic part advisory, and put a deterministic, human-gated executor in charge of anything that cannot be undone.

How it works

The line that organizes everything: read vs write

Propose vs execute — the split that makes it safe

How automation scales without moving the safety line

Related cards

agentic-intent-veto and simulate-before-sign (a check/veto outside the model, before the irreversible act), constraint-was-the-product ("not a prompt" as the boundary; fewer tools = better judgment), the-boundary-is-the-unit (single-point governance), a-boolean-hides-a-state-machine (non-determinism: one good run proves nothing), what-encryption-does-not-hide (a masked+hashed audit log that isn't its own leak path).

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

에이전트에게 쓸 권한이 아니라 요청할 권한만 준다

삼성계정(약 21억 사용자)이 Bedrock AgentCore 위에 프로덕션 멀티 에이전트 AIOps 시스템을 구축했고, 하중을 받는 선택은 모델이 아니라 권한 경계입니다 — 에이전트는 쓰기 권한이 없고 정확한 커맨드를 제안만 하며, 사람이 검토한 뒤 별도의 결정적 스케줄러가 승인된 산출물을 그대로 실행합니다. 분석은 틀려도 다시 검증하면 되지만, 실행이 틀리면 돌이킬 수 없습니다. "프롬프트가 아닌 무언가로 판단과 실행을 분리하라"의 실제 배포판입니다.

아직 범위 미정 — 프로덕션을 건드리는 모든 에이전트에 적용할 수 있는 설계 패턴 연구입니다. 먼저 에이전트의 행동을 읽기(분석)와 쓰기(실행)로 나누고, 쓰기 경로가 LLM 을 아예 거치지 않는지 확인합니다. 그다음 제안/실행 분리를 구현합니다 — 에이전트는 무엇을 실행할지(정확한 커맨드·코드)를 등록하고, 사람이 그 산출물을 그대로 검토하고, 결정적 실행자가 승인된 산출물을 재생성 없이 그대로 실행합니다. 그들이 쓰는 성숙도 사다리를 더합니다 — Level 1 은 읽기 전용 교차 도메인 분석(위험 낮고 시간 가장 많이 잡아먹음), Level 2 는 계획 → 승인 → 실행이고, 게이트는 정확히 읽기/쓰기 선에 있습니다. 단일 입구 가드레일을 얹습니다 — 모든 요청이 수렴하는 Orchestrator 하나에 PII 마스킹·라우팅·장기 메모리가 한 번 적용 — 그래서 에이전트를 늘려도 경계가 흩어지지 않습니다. 측정 가능한 질문: 당신의 운영 잡무 중 읽기 전용 분석(오늘 안전히 자동화 가능) 대 쓰기 행동(게이트)의 비중은 얼마이고, 자동화는 에이전트 권한이 아니라 실행자 절차를 더해 자라는가? 출처: AWS 블로그, 삼성계정 SRE, "삼성계정 AIOps" Part 1, 2026-09-03 — AgentCore 벤더 쇼케이스; 제품 프레이밍은 가중하되 패턴이 요점.

왜

한 문장이 설계 전체를 나릅니다 — 분석은 틀려도 사람이 검증하지만 실행이 틀리면 돌이킬 수 없으므로, 에이전트에게는 요청할 권한만 주고 쓸 권한은 주지 않는다. 에이전트는 정확한 커맨드·코드를 제안하고, 별도의 결정적 스케줄러가 승인된 산출물을 그대로 실행하며, LLM 은 쓰기 경로를 결코 건드리지 않습니다. 승인 게이트 뒤에서 비결정적 판단과 결정적 실행을 떼어놓는 것. 이 목록이 사방에서 도달했던 원칙의 프로덕션 형태입니다 — agentic-intent-veto(모델 밖에 사는 거부권), simulate-before-sign(돌이킬 수 없는 행동 전 검사), 그리고 constraint-was-the-product 의 마무리 — untrusted 입력을 읽으면서 중대한 행동도 할 수 있는 에이전트는 그 둘을 프롬프트가 아닌 무언가로 분리해야 한다. 여기서 그 무언가는 스케줄러 + 정확한 산출물에 대한 사람의 승인입니다.

확장 방식이 반직관적이고, constraint-was-the-product 와 같은 교훈입니다. 더 많이 자동화하려 에이전트에게 더 큰 권한을 준 게 아니라, 에이전트를 요청-전용으로 얼리고 실행자가 안전히 돌릴 수 있는 절차 목록을 늘렸습니다. 자동화는 검증된 실행 경로를 더해 넓어지지, 에이전트 권한을 풀어 넓어지지 않으므로, 커버리지가 커져도 사람이 통제하는 안전선은 제자리입니다. 그리고 3계층 구조 — Orchestrator → 도메인 Supervisor → Sub-agent — 는 GitHub 가 Copilot 도구를 40 → 13 으로 줄인 그 이유로 존재합니다: 단일 에이전트의 판단은 도구·도메인이 늘수록 나빠지므로, 책임을 도메인으로 나눠 각 에이전트가 작고 검토 가능한 표면만 봅니다. 에이전트당 도구가 적을수록 판단이 낫다 — 한 조직 건너 같은 발견.

거버넌스는 의도적으로 단일 지점이고, 이것이 소프트웨어로 구현된 the-boundary-is-the-unit 입니다. 모든 요청이 Orchestrator 하나로 수렴해 거기서 가드레일(PII 마스킹)·라우팅·메모리가 한 번 적용되므로, N 개 에이전트가 N 개 경계가 되지 않습니다 — 에이전트를 더해도 거버넌스는 움직이지 않습니다. 감사 로그마저 자기 자신이 유출 경로가 되지 않게 단단히 합니다 — 탐지된 PII 는 원본이 아니라 마스킹·해시로 저장되며, 정확히 관측 계층에 적용된 what-encryption-does-not-hide 입니다. 그 아래에는 정직한 전제 하나가 있습니다 — LLM 은 비결정적이고, 만 번의 좋은 실행이 만한 번째를 증명하지 않는다, a-boolean-hides-a-state-machine 의 경고를 운영 형태로. 답은 더 나은 프롬프트가 아니라 구조입니다 — 비결정적 부분은 자문으로 두고, 되돌릴 수 없는 것은 결정적이고 사람이 게이트하는 실행자에게 맡긴다.

동작 방식

모든 것을 조직하는 선: 읽기 대 쓰기

제안 대 실행 — 안전하게 만드는 분리

안전선을 옮기지 않고 자동화를 넓히는 법

관련 카드

agentic-intent-veto·simulate-before-sign(돌이킬 수 없는 행동 전, 모델 밖의 검사/거부권), constraint-was-the-product(경계로서의 "프롬프트 아님"; 도구 적을수록 판단 나음), the-boundary-is-the-unit(단일 지점 거버넌스), a-boolean-hides-a-state-machine(비결정성: 한 번 잘 됐다고 증명 아님), what-encryption-does-not-hide(자기 유출 경로가 아닌 마스킹·해시 감사 로그).

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑