본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 07. 22:04

AI 에이전트에게 필요한 것은 더 많은 프롬프트가 아니라 실행 경계(Execution Boundaries)입니다

요약

AI 에이전트가 도구를 사용하여 실제 동작을 수행할 때, 프롬프트 제어만으로는 보안을 보장할 수 없습니다. 본문은 에이전트의 오류나 공격으로부터 시스템을 보호하기 위해 암호화된 증명을 기반으로 실행 여부를 결정하는 '실행 경계(Execution Boundaries)'의 중요성을 강조합니다.

핵심 포인트

  • 프롬프트 기반 제어는 에이전트의 실제 실행 단계에서 한계가 있음
  • 에이전트의 잘못된 도구 호출로 인한 부작용(Side effect) 방지 필요
  • Actenon Kernel은 암호화 증명을 통해 실행 권한을 검증하는 방식 제안
  • 모델의 신뢰도가 아닌, 동작의 유효한 증거를 기반으로 실행 결정

AI 에이전트(AI agents)가 채팅에서 실행(action)의 단계로 넘어가고 있습니다.

에이전트는 도구(tools)를 호출하고, 이메일을 보내고, 레코드를 업데이트하고, 데이터를 삭제하며, 워크플로(workflows)를 트리거하고, 코드를 배포하고, 환불을 처리하고, IAM 권한을 변경하며, MCP 서버와 상호작용할 수 있습니다.

이러한 변화는 강력합니다.

하지만 동시에 위험해지기 시작하는 지점이기도 합니다.

대부분의 AI 안전(AI safety) 논의는 여전히 모델(model)에 집중되어 있습니다:

  • 모델이 지침을 따르게 만들 수 있는가?
  • 프롬프트 인젝션(prompt injection)을 막을 수 있는가?
  • 에이전트가 더 잘 추론하게 만들 수 있는가?
  • 환각(hallucinating)을 멈추게 할 수 있는가?

이러한 질문들은 중요합니다.

하지만 가장 중요한 순간을 놓치고 있습니다:

에이전트가 실제로 무언가를 실행하려는 바로 그 순간에는 어떤 일이 벌어지는가?

왜냐하면 그 시점에서는 프롬프트(prompt)가 더 이상 제어 표면(control surface)이 아니기 때문입니다.

실행 경계(execution boundary)가 제어 표면이 됩니다.

문제점: 에이전트가 틀릴 수 있지만, 부작용(side effect)은 여전히 발생한다

환불 도구(refund tool)에 연결된 에이전트를 상상해 보십시오.

사용자가 요청합니다:

ord-123 주문에 대해 £25를 환불해 줘.

에이전트는 다음과 같이 올바르게 호출합니다:

python issue_refund(order_id="ord-123", amount_cents=2500)

좋습니다.

하지만 이제 에이전트가 프롬프트 인젝션(prompt-injected)을 당했거나, 혼란에 빠졌거나, 침해되었거나, 혹은 단순히 틀렸다고 가정해 봅시다.

에이전트는 다음과 같이 호출합니다:

python issue_refund(order_id="ord-456", amount_cents=250000)

또는 동일한 환불을 두 번 반복할 수도 있습니다.

또는 한 고객을 위해 의도된 증거를 다른 고객에게 사용할 수도 있습니다.

혹은 사용자가 실제로 승인한 것보다 더 위험한 도구를 호출할 수도 있습니다.

그 시점에서, 다른 시스템이 결정해야 합니다:

이 정확한 동작이 발생하는 것이 허용되는가?

“모델이 신뢰할 수 있어 보이는가?”가 아닙니다.

“프롬프트에서 주의하라고 말했는가?”도 아닙니다.

“이것이 원래 요청과 대략적으로 유사해 보이는가?”도 아닙니다.

질문은 이것입니다:

지금 이 순간, 이 정확한 서비스에 대해, 이 정확한 매개변수(parameters)를 가진, 이 정확한 동작에 대한 유효한 증거(valid proof)가 있는가?

만약 없다면, 부작용(side effect)은 실행되어서는 안 됩니다.

아이디어: 유효한 증거가 없으면 실행도 없다

저는 Actenon Kernel이라는 오픈 소스 프로젝트를 작업해 왔습니다.

아이디어는 간단합니다:

AI 에이전트는 동작을 제안할 수 있습니다. 보호된 시스템(Protected systems)은 해당 동작의 실행 허용 여부를 결정합니다.

Actenon은 프롬프트 필터(prompt filter)가 아닙니다.

그것은 출력 중재자(output moderator)도 아닙니다.

모델을 진실되게 만들려고 시도하지도 않습니다.

Actenon은 실행 경계(execution boundary)에 위치하며, 호출자가 시도 중인 정확한 동작에 결합된 암호화 증명(cryptographic proof)을 제시하지 않는 한 중대한 결과가 따르는 동작을 거부합니다.

해당 증명은 다음 항목들을 결합할 수 있습니다:

  • 동작 이름 (the action name)
  • 권한 (the capability)
  • 정확한 파라미터 (the exact parameters)
  • 대상 리소스 (the target resource)
  • 의도된 대상/서비스 (the intended audience/service)
  • 만료 시간 (expiry time)
  • 재전송 공격 방지 (replay protection)
  • 정책 또는 승인 증거 (policy or approval evidence)

만약 증명이 누락되었거나, 만료되었거나, 재전송되었거나, 대상이 일치하지 않거나, 형식이 잘못되었거나, 혹은 다른 파라미터에 결합되어 있다면, 부수 효과(side effect)가 발생하기 전에 해당 동작은 거부됩니다.

아주 작은 예시

멘탈 모델(mental model)은 다음과 같습니다:

from actenon import ActenonGate

gate = ActenonGate.local_dev(audience="service:refunds")

action = gate.build_action(
    "refund.issue",
    "payment.refund",
    {"order_id": "ord-123", "amount_cents": 2500},
    target_type="order",
    target_id="ord-123",
    tenant_id="demo",
    requester_id="support-agent",
)

# 로컬 데모용입니다.
# 프로덕션 환경에서는 이 증명이 인증 계층(auth layer), 
# 정책 엔진(policy engine), 승인 워크플로우(approval workflow), 
# 또는 컨트롤 플레인(control plane)에 의해 발행(mint)될 것입니다.

proof = gate.mint_proof(action)

outcome = gate.protect(
    action,
    proof,
    lambda: issue_refund("ord-123", 2500),
    audience="service:refunds",
)

중요한 부분은 람다(lambda) 함수입니다.

만약 증명이 유효하지 않다면, 해당 함수는 절대 실행되지 않습니다.

모델은 요청할 수 있습니다.

경계(boundary)가 결정합니다.

이것이 MCP와 에이전트 도구에 중요한 이유

MCP는 에이전트가 도구에 도달하는 것을 더 쉽게 만들어 줍니다.

그것은 유용합니다.

하지만 이는 모델에게 노출된 도구가 실제 시스템으로 들어가는 가교가 될 수 있음을 의미하기도 합니다: 파일 시스템(filesystems), 데이터베이스(databases), CRM, 터미널(terminals), 배포 파이프라인(deployment pipelines), 결제 시스템(payment systems), 그리고 내부 관리 워크플로우(internal admin workflows) 등이 그 대상입니다.

따라서 질문은 다음과 같습니다:

특정 호출을 실행할지 여부를 도구가 어떻게 결정할 것인가?

Actenon의 답변은 MCP 도구가 모델이 올바르게 행동할 것에 의존해서는 안 된다는 것입니다. 실행 시점에 증명을 요구해야 합니다.

프롬프트 주입(prompt-injected)된 에이전트가 도구를 호출할 수도 있습니다.

증명이 정확한 동작과 일치하지 않는 한 도구는 여전히 거부합니다.

이것이 IAM과 다른 이유

IAM은 다음과 같이 답합니다:

누가 또는 무엇이 접근 권한을 가지고 있는가?

Actenon은 다음과 같이 답합니다:

이 정확한 에이전트 동작(agentic action)이 지금 이 순간 승인되었는가?

이것들은 서로 다른 제어 방식입니다.

에이전트가 환불 API에 대한 접근 권한을 가질 수 있습니다.

하지만 그것이 모든 환불 금액, 모든 고객, 모든 재시도, 그리고 모든 대상이 허용되어야 함을 의미하지는 않습니다.

IAM은 필요합니다.

하지만 자율적(autonomous) 또는 반자율적(semi-autonomous) 에이전트의 경우, 실행 시점(execution time)에서 항상 충분히 세밀하지(granular) 않을 수 있습니다.

로컬 데모

리포지토리(repo)에는 아주 작은 대화형 데모가 포함되어 있습니다:

bash python examples/interactive_execution_demo.py

다음 내용을 보여줍니다:

text ✅ 승인된 환불: ord-123 £25.00 -> 실행됨 🛑 환각된(hallucinated) 환불: ord-456 £2,500.00 -> 거부됨 / INTENT_MISMATCH 🛑 승인된 환불 재생(replay) -> 거부됨 / DUPLICATE_REPLAY 🛑 증명이 없는 환불 -> 거부됨 / PCCB_REQUIRED

승인된 동작만이 사이드 이펙트(side-effect) 함수에 도달합니다.

그 외의 모든 것은 폐기됩니다.

제가 찾고 있는 것

다음 기술들을 사용하여 구축 중인 분들의 피드백을 받고 싶습니다:

  • MCP
  • LangChain / LangGraph
  • Claude tools
  • OpenAI tool calling
  • 코딩 에이전트 (coding agents)
  • 내부 워크플로우 에이전트 (internal workflow agents)
  • 에이전트 기반 CI/CD (agentic CI/CD)
  • AI 관리 도구 (AI admin tools)
  • 금융, 의료, IAM 또는 규제 대상 워크플로우 (finance, healthcare, IAM, or regulated workflows)

제가 정교하게 다듬고자 하는 질문은 다음과 같습니다:

실제 세계의 에이전트 아키텍처에서 증명 경계(proof boundary)는 어디에 위치해야 하는가?

도움이 될 수 있다면, 리포지토리는 여기 있습니다:

https://github.com/Actenon/actenon-kernel

목표는 모든 에이전트를 안전하게 만드는 것이 아닙니다.

목표는 중대한 결과가 발생하는 동작 표면(consequential action surfaces)을 결정론적(deterministic)으로 만드는 것입니다.

유효한 증명이 없다면, 실행도 없습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0