agent control plane은 실행을 둘러싼 결정, 즉 identity, authorization, credential scope, approval, limit, operation status, resource ownership, audit record를 소유합니다. data plane은 허용된 database query, browser action, deployment, API call을 수행합니다.
각 도구가 이런 결정을 서로 다르게 내린다면 시스템에 실질적인 control plane이 없는 것입니다. 도구가 추가되면서 어긋나는 관례만 모여 있을 뿐입니다.
결정과 실행을 분리하세요
flowchart LR
Agent[Agent request] --> Identity[Resolve identity and tenant]
Identity --> Policy{Policy and approval}
Policy -->|deny| Audit[Audit decision]
Policy -->|allow| Broker[Issue scoped credential]
Broker --> Operation[Create or resume operation]
Operation --> Tool[Execute tool in data plane]
Tool --> Resource[(Database, API, browser, compute)]
Tool --> Operation
Operation --> Audit
control plane은 누가 작업하는지, 어떤 리소스를 소유하는지, 어떤 작업이 허용되는지, 동의가 필요한지, 얼마만큼 실행할 수 있는지, 작업을 어떻게 중단할 수 있는지 답해야 합니다. data plane은 범위가 좁은 지시와 이를 수행하는 데 필요한 만큼의 권한을 받아야 합니다.
이 경계는 전체 AI agent 아키텍처를 보완합니다. 첫날부터 별도의 서비스일 필요는 없지만 contract가 코드에 보여야 합니다.
도구 선택보다 identity를 먼저 확인하세요
도구를 실행하기 전에 인증된 human, tenant, agent, session을 확인하세요. 서버가 credential에서 tenant identifier를 연결할 수 있다면 model output에서 그 값을 받지 마세요.
NIST의 zero trust architecture는 caller가 network 안에 있다는 이유로 신뢰를 부여하지 않고 요청마다 신뢰를 평가합니다. agent의 경우 내부 도구가 요청했더라도 다운스트림 서비스에서 해당 신원의 권한을 다시 확인해야 한다는 뜻입니다.
control plane, agent session, application runtime에는 서로 다른 자격 증명을 사용하세요. 리소스를 provision할 수 있는 management 자격 증명을 일반 application call에 노출해서는 안 됩니다.
policy가 구체적인 결정을 반환하게 하세요
유용한 policy 결정은 다음 내용을 기록합니다.
- subject, tenant, resource, action
- policy version 및 일치한 rule
- human approval 필요 여부
- spend, call, time, data volume 제한
- 안정적인 reason이 포함된 allow 또는 deny 결과
도구 설명은 모델이 언제 승인을 요청해야 하는지 알려 줄 수 있지만, 강제는 prompt 바깥에서 이루어져야 합니다. OWASP의 Excessive Agency 가이드는 도구의 기능, 권한, 자율성을 최소화하고 다운스트림 시스템에서 권한을 적용할 것을 권장합니다.
가능한 가장 좁은 범위로 자격 증명을 중개하세요
provider가 지원한다면 data-plane worker는 승인된 리소스와 작업에 대한 단기 자격 증명을 받아야 합니다. provider가 지원하지 않는다면 provider 자격 증명을 server-side 도구에 두고 wrapper에서 같은 제한을 적용하세요.
secret을 model context, 도구 설명, URL, 모델에 보이는 error에 전달하지 마세요. trace에는 credential 값이 아니라 credential reference를 기록하세요.
agent 보안 가이드는 전체 identity 및 secret 경로를 설명합니다.
operation과 conversation을 따로 추적하세요
chat turn은 operation record가 아닙니다. 쓰거나, 기다리거나, 재시도하거나, 요청보다 오래 지속될 수 있는 작업에는 operation ID를 만드세요. status, redaction 이후 input, idempotency key, approval state, attempt, output 또는 reference, 최종 result를 저장합니다.
이렇게 하면 agent가 deployment 요청을 다시 실행하지 않고도 아직 실행 중인지 물을 수 있습니다. 사람에게도 취소, 재개, 조사할 수 있는 안정적인 object가 생깁니다.
inventory와 ownership을 같은 plane에 두세요
control plane은 각 database, bucket, deployment, browser session, agent credential을 어느 tenant가 소유하는지 알아야 합니다. inventory가 있으면 revocation과 deletion을 처리하기 쉽습니다. 두 tenant에 같은 friendly name의 리소스가 있을 때 모델이 잘못 선택하는 것도 막을 수 있습니다.
모델이 제공한 tenant field가 아니라 인증된 tenant와 operation에 quota를 적용하세요. limit에 걸리면 agent가 무작정 재시도하지 않고 설명할 수 있도록 안정적인 결과를 반환해야 합니다.
결정과 결과를 함께 감사하세요
audit record에는 policy decision과 관찰된 outcome이 모두 필요합니다. “Allowed delete”와 “delete completed”는 서로 다른 event입니다. operation ID, actor, tenant, resource, action, policy version, approval reference, timestamp, result class를 보관하세요.
기본적으로 raw prompt, secret, 전체 tool result를 audit log에 넣지 마세요. 정확한 내용을 보관해야 한다면 별도의 access policy 아래에 hash나 reference를 저장하세요.
기존 애플리케이션 안에서 시작하세요
소규모 시스템은 middleware, policy module, credential adapter, operations table, append-only audit table로 이를 구현할 수 있습니다. 규모나 소유권 때문에 필요할 때 서비스로 분리하세요. 첫 목표는 일관된 decision path 하나를 만드는 것입니다.
아래 프롬프트는 기존 workflow를 추적해 개별 tool handler에 묻힌 제어를 찾습니다. 이런 중복이 shared contract 뒤로 옮길 첫 후보입니다.