AI 에이전트에는 가드레일(guardrails)뿐만 아니라 거버넌스 계층(governance layer)이 필요합니다

당신의 AI 에이전트가 새벽 2시 47분에 240만 달러의 대출 집행을 승인했습니다. 아무도 검토하지 않았습니다. 고객의 전화를 받고서야 이 사실을 알게 됩니다. 로그를 확인해보지만 유의미한 것은 없습니다. 프롬프트(prompt)를 확인해보니 괜찮아 보입니다. 출력 검증기(output validator)를 확인해보니 통과되었습니다. 어떤 정책 버전이 실행되었는지, 모델이 어떤 신호(signals)를 보았는지, 혹은 그 시점부터 지금까지 누군가 기록을 조작할 수 있었는지 전혀 알 수 없습니다. 당신은 완전히 무방비 상태입니다.

이것은 가설이 아닙니다. 승인, 집행, 에스컬레이션(escalations), 데이터 접근과 같이 실제적인 결과가 따르는 결정을 내리는 에이전트를 출시하고 있다면, 당신은 결국 당신을 이런 상황에 처하게 만들 시스템을 이미 구축한 것입니다.

"가드레일(guardrails)"의 문제점
AI 안전 도구 생태계는 하나의 패턴으로 수렴되었습니다: 모델을 감싸고(wrap), 출력을 검증하며, 아마도 신뢰도 임계값(confidence threshold)을 추가하는 것입니다. 출력이 잘못되어 보이면 거부합니다. 이것이 가드레일입니다. 이것은 거버넌스(governance)가 아닙니다.

중요한 차이점은 다음과 같습니다:
프롬프트 엔지니어링(Prompt engineering)은 모델에게 무엇을 선호할지 알려줍니다. 실행 시점에서의 강제력이 없으며, 법적으로 유의미한 버전 관리(version control)가 없고, 작성된 대로 실행되었다는 증거도 없습니다.

If/else 출력 검증(output validation)은 애플리케이션 코드입니다. 배포할 때마다 변경되며, 우연히 기록하는 로그 이외에는 감사 추적(audit trail)이 없고, 아무도 표시하지 않은 코드 변경에 의해 너무나 쉽게 우회될 수 있습니다.

LLM 출력 검증기(LLM output validators: JSON schema 체크, 신뢰도 임계값, 분류기 기반 필터)는 출력이 수용 가능한지 여부를 알려줍니다. 하지만 어떤 정책 버전이 실행되었는지, 내일 동일한 입력값이 주어졌을 때 동일한 결정에 도달할 것인지, 혹은 실행 이후에 기록이 수정되었는지 여부는 알려줄 수 없습니다.

이 중 어느 것도 검증 가능한 기록(verifiable record)을 생성하지 않습니다. 이들은 로그(logs)를 생성할 뿐입니다. 로그는 변경 가능(mutable)합니다. 로그는 불완전합니다. 로그는 증거가 아닙니다.

컴플라이언스(compliance) 팀이 "이 특정 대출이 이 특정 입력값과 함께 이 특정 정책 버전에 의해 승인되었음을 보여주고, 그것이 변경되지 않았음을 증명하세요"라고 요청할 때, 로그는 그 질문에 답할 수 없습니다.

암호학적 증명 (Cryptographic attestation)은 가능합니다. 거버넌스 (Governance)가 실제로 의미하는 것: 네 가지 속성. 만약 당신의 의사결정 시스템이 이 네 가지를 모두 갖추지 못했다면, 그것은 거버넌스가 아닙니다.

1. 결정론 (Determinism): 동일한 정책 버전과 동일한 입력이 주어지면, 항상 동일한 출력을 얻어야 합니다. 무작위성(randomness), 모델 온도(model temperature), 숨겨진 상태(hidden state)가 없어야 합니다. 의사결정은 순수 함수 (pure function)여야 합니다. 비유: 기록으로부터 다시 도출할 수 있는 법원의 판결.

2. 암호학적 증명 (Cryptographic attestation): 의사결정, 입력값, 그리고 정책 버전이 함께 해싱 (hashed)되어 실행 시점에 개인 키 (private key)로 서명됩니다. 서명 검증이 실패하지 않고서는 사후에 그 누구도 기록을 수정할 수 없습니다. 비유: 공증인의 인장이 문서가 변조되지 않았음을 증명하는 공증된 문서.

3. 재전송 공격 방지 (Replay protection): 각 실행은 정책 ID, 버전, 그리고 정형 입력 해시 (canonical input hash)로부터 유도된 고유한 지문 (fingerprint)을 가집니다. 동일한 지문은 두 번 제출될 수 없습니다. 비유: 일련번호가 있는 수표는 한 번 현금화되면 다시 현금화할 수 없습니다.

4. 독립적 검증 가능성 (Independent verifiability): 공개 키 (public key)를 보유한 어떤 당사자라도 라이브 시스템, 데이터베이스, 또는 어떠한 런타임 상태 (runtime state)에 대한 접근 권한 없이도 증명을 검증할 수 있습니다. 증명은 그 자체로 완결성을 가집니다. 비유: 누구나 PGP로 서명된 메시지를 검증할 수 있으며, 작성자에게 연락할 필요가 없습니다.

이 네 가지 속성이 바로 "올바른 정책이 실행되었다고 생각한다"를 "올바른 정책이 실행되었음을 증명할 수 있다"로 바꾸어 놓는 요소입니다.

코드 보기
다음은 @parmanasystems/core를 사용하는 대출 승인 에이전트의 예시입니다. AI 모델은 권장 사항을 생성합니다. Parmana Systems는 시스템이 해당 권장 사항에 따라 행동할 권한이 있는지 여부를 강제합니다.

import crypto from "crypto";
import { executeFromSignals, LocalSigner, LocalVerifier, MemoryReplayStore } from "@parmanasystems/core";

// 당신의 Ed25519 키 쌍 — 프로덕션 환경에서는 AWS KMS 또는 이와 유사한 서비스를 사용하세요
const { privateKey, publicKey } = crypto.

generateKeyPairSync ( " ed25519 " , { privateKeyEncoding : { type : " pkcs8 " , format : " pem " }, publicKeyEncoding : { type : " spki " , format : " pem " }, }); const signer = new LocalSigner ( privateKey ); const verifier = new LocalVerifier ( publicKey ); const replayStore = new MemoryReplayStore (); // 신호(Signals)는 AI 파이프라인, 데이터 계층, 리스크 엔진에서 전달됩니다 // 모델은 승인을 권장했습니다 — 이제 거버넌스(governance)가 실행 가능 여부를 결정합니다 const attestation = await executeFromSignals ( { policyId : " loan-approval " , policyVersion : " 2.1.0 " , signals : { applicant_id : " usr_8f3k2p " , requested_usd : 240000 , credit_score : 712 , dti_ratio : 0.31 , employment_months : 26 , model_recommendation : " approve " , // LLM으로부터 전달됨 }, }, signer , verifier , replayStore ); console . log ( attestation . execution_state ); // "completed" console . log ( attestation . decision . action ); // "approve" console . log ( attestation . signature ); // "mK3nQs8rXpLw2YbD9eHtNcAoGiUjZlV0TfRkMyPh1CxBs6WqJ5IuEdOgPm4..." // ↑ 정형화된 검증(canonical attestation) JSON에 대한 Ed25519 — 64바이트, base64 인코딩됨

model_recommendation은 단지 또 다른 신호(signal)일 뿐입니다. 거버넌스 계층(governance layer)은 실행 조건이 충족되었는지 여부를 결정하며, 모델은 정책(policy)이 규정하는 내용에 대해 투표권을 갖지 않습니다. 만약 credit_score가 정책 임계값(threshold) 아래로 떨어지면, 모델이 무엇을 권장했는지와 관계없이 execution_state: "blocked"를 받게 됩니다.

실제로 받게 되는 결과
executeFromSignals를 호출할 때마다 ExecutionAttestation을 반환합니다. 각 필드가 증명하는 내용은 다음과 같습니다:

{
executionId : " a3f2b1c4d8e7f96a... " , // 정책 + 버전 + 정형화된 신호(canonical signals)의 SHA-256
policyId : " loan-approval " ,
policyVersion : " 2.1.0 " , // "latest"가 아닌 정확한 버전
signalsHash : " 8b3f9c2a... " , // 정형화된 입력 신호(canonical input signals)의 SHA-256
decision : {
action : " approve " ,
requires_override : false ,
reason : " all thresholds met "
},
execution_state : " completed " , // "completed" | "blocked" | "pending_override"
runtimeHash : " 7d4e1f8a..."

, // 실행 시점의 런타임 바이너리 상태의 해시 runtimeVersion : " 1.65.0 " , signature : " mK3nQs8rXp... " // 위의 모든 항목에 대한 Ed25519 서명 } 이 서명이야말로 이것을 단순한 로깅 (logging)이 아닌 거버넌스 (governance)로 만드는 요소입니다. 서명은 전체 증명 (attestation)의 정준 JSON 직렬화 (canonical JSON serialization) — 결정론적 키 순서 (deterministic key ordering), 공백 변동 없음 — 를 기반으로 계산됩니다. 서명 후 어떤 필드라도 수정되면 검증 (verification)이 실패합니다. 귀사의 컴플라이언스 (compliance) 팀은 데이터베이스나 운영 환경 (production)에 대한 접근 권한 없이도 이 기록을 오프라인으로 가져가 검증할 수 있습니다: import { verifyAttestation , LocalVerifier } from " @parmanasystems/core " ; const verifier = new LocalVerifier ( publicKey ); // 공개 키 (public key)만 사용 — 비밀값 없음 const valid = verifyAttestation ( attestation , verifier ); // true — 또는 실패한 특정 필드와 함께 오류 발생 이들은 이진 (binary) 답변을 받게 됩니다: 이 기록이 변조되지 않은 진본인지, 아니면 아닌지 말입니다. 귀사의 로깅 인프라 (logging infrastructure)를 신뢰할 필요가 없습니다. 귀사의 운영 데이터베이스 (production database)에 접근할 필요도 없습니다. 귀사의 말을 믿을 필요도 없습니다. 이것이 "여기 우리 로그가 있습니다"와 "여기 암호학적 증명 (cryptographic proof)이 있습니다"의 차이입니다. 누가 이에 관심을 가져야 할까요? 신용 결정, 결제 승인 또는 트레이딩 워크플로 (trading workflows)를 배포하는 핀테크 (Fintech) 엔지니어들, 특정 정책 버전이 특정 트랜잭션 (transaction)을 관리했음을 증명해야 하는 모든 관할 구역. MiFID II, SOC 2, PCI, Basel III는 모두 로그만으로는 완전히 충족할 수 없는 감사 (audit) 요구 사항을 가지고 있습니다. 서명된 증명 (signed attestation)은 이를 충족합니다. 도구 사용 (tool-use), 자율 파이프라인 (autonomous pipelines) 또는 다단계 결정 체인 (multi-step decision chains)을 갖춘 LLM 에이전트를 구축하는 AI 플랫폼 팀들. 에이전트가 실제 세계에 영향을 미치는 동작 — 돈을 보내거나, 기록을 수정하거나, 결정을 에스컬레이션(escalate)하는 등 — 을 트리거할 수 있는 순간, 귀하에게는 무엇이 해당 동작을 승인했는지 증명할 수 있는 계층 (layer)이 필요합니다. "모델이 결정했습니다"는 감사 추적 (audit trail)이 아닙니다.

돈, 데이터, 또는 미래의 규제 기관, 감사인, 고객, 혹은 법무팀이 "올바른 입력값과 함께 올바른 정책이 실행되었음을, 그리고 아무도 기록을 변경하지 않았음을 증명하십시오"라고 요구할 수 있는 결정에 관여하는 자율 시스템 (autonomous systems)을 구축하는 사람이라면 누구나 이를 고려해야 합니다. 만약 오늘 그 질문에 답할 수 없다면, 결국 가장 최악의 타이밍에 그 질문을 받게 될 것입니다. 패턴은 항상 동일합니다. 무언가 잘못되고, 누군가 증명을 요구하면, 당신의 로깅 아키텍처 (logging architecture)가 증명을 위한 것이 아니라 디버깅 (debugging)을 돕기 위해 설계되었다는 사실을 깨닫게 됩니다.

Try it Parmana Systems는 Apache 2.0 라이선스 하에 오픈 소스 (open source)로 제공됩니다. npm install @parmanasystems/core Docs : parmanasystems.mintlify.app Source : github.com/pavancharak/parmanasystems-core

퀵스타트 (quickstart)를 이용하면 5분 이내에 서명된 증명 (signed attestation)을 생성할 수 있습니다. 대출 승인 정책 (loan approval policy)이 작동 가능한 예시로 포함되어 있습니다. 이미 프로덕션 (production) 환경에서 에이전트 (agent)를 운영 중이라면, 통합 인터페이스 (integration surface)는 기존의 결정 로직 (decision logic)을 감싸는 단일 함수 호출 (single function call)뿐입니다. 거버넌스 (governance)는 무언가 잘못된 후에 추가하는 것이 아닙니다. 거버넌스는 아무것도 잘못되지 않았음을 증명할 수 있게 해주는 것입니다.