haechi 0.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +154 -0
- package/README.md +102 -0
- package/SECURITY.md +31 -0
- package/docs/README.md +35 -0
- package/docs/current/api-stability.ko.md +48 -0
- package/docs/current/api-stability.md +48 -0
- package/docs/current/expert-gap-review-ai-llm-mcp-encryption.ko.md +107 -0
- package/docs/current/expert-gap-review-ai-llm-mcp-encryption.md +107 -0
- package/docs/current/global-privacy-compliance-review.ko.md +110 -0
- package/docs/current/global-privacy-compliance-review.md +110 -0
- package/docs/current/initial-plan-ai-llm-mcp-encryption.ko.md +214 -0
- package/docs/current/initial-plan-ai-llm-mcp-encryption.md +214 -0
- package/docs/current/mvp-0.1-implementation-scope.ko.md +79 -0
- package/docs/current/mvp-0.1-implementation-scope.md +79 -0
- package/docs/current/open-source-modular-architecture.ko.md +387 -0
- package/docs/current/open-source-modular-architecture.md +387 -0
- package/docs/current/prd-ai-llm-mcp-encryption.ko.md +260 -0
- package/docs/current/prd-ai-llm-mcp-encryption.md +262 -0
- package/docs/current/privacy-filtering-policy-draft.ko.md +307 -0
- package/docs/current/privacy-filtering-policy-draft.md +307 -0
- package/docs/current/release-0.2-implementation-scope.ko.md +46 -0
- package/docs/current/release-0.2-implementation-scope.md +46 -0
- package/docs/current/release-0.3-implementation-scope.ko.md +86 -0
- package/docs/current/release-0.3-implementation-scope.md +86 -0
- package/docs/current/release-0.3.2-hardening-scope.ko.md +64 -0
- package/docs/current/release-0.3.2-hardening-scope.md +64 -0
- package/docs/current/release-0.4-implementation-scope.ko.md +121 -0
- package/docs/current/release-0.4-implementation-scope.md +121 -0
- package/docs/current/release-process.ko.md +48 -0
- package/docs/current/release-process.md +48 -0
- package/docs/current/risk-register-release-gate.ko.md +154 -0
- package/docs/current/risk-register-release-gate.md +154 -0
- package/docs/current/shared-responsibility.ko.md +38 -0
- package/docs/current/shared-responsibility.md +38 -0
- package/docs/current/threat-model.ko.md +68 -0
- package/docs/current/threat-model.md +68 -0
- package/examples/llm-prompt-filtering/input.json +13 -0
- package/examples/plugins/custom-filter.plugin.json +29 -0
- package/haechi.config.example.json +70 -0
- package/package.json +74 -0
- package/packages/audit/index.mjs +262 -0
- package/packages/cli/bin/haechi.mjs +341 -0
- package/packages/cli/runtime.mjs +287 -0
- package/packages/core/index.mjs +309 -0
- package/packages/crypto/index.mjs +142 -0
- package/packages/filter/index.mjs +189 -0
- package/packages/mcp-stdio/index.mjs +105 -0
- package/packages/plugin/index.mjs +83 -0
- package/packages/policy/index.mjs +165 -0
- package/packages/policy-bundle/index.mjs +91 -0
- package/packages/privacy-profiles/index.mjs +92 -0
- package/packages/protocol-adapters/index.mjs +111 -0
- package/packages/proxy/index.mjs +534 -0
- package/packages/token-vault/index.mjs +262 -0
|
@@ -0,0 +1,262 @@
|
|
|
1
|
+
# PRD: AI/LLM/MCP Encryption Solution
|
|
2
|
+
|
|
3
|
+
- Status: Draft 0.1
|
|
4
|
+
- Date: 2026-06-08
|
|
5
|
+
- Product: Haechi
|
|
6
|
+
- Target version: Realignment of the initial PRD/SRS/security-review archive toward AI/LLM/MCP-specific requirements
|
|
7
|
+
|
|
8
|
+
## 1. Purpose
|
|
9
|
+
|
|
10
|
+
Haechi is an encryption solution that protects prompts, contexts, tool calls, resources, retrieval snippets, artifacts, and streaming events flowing through AI applications, LLM gateways, MCP clients/servers, agent runtimes, and A2A agent networks.
|
|
11
|
+
|
|
12
|
+
The core objective is not merely transport-layer protection. Instead, it elevates the semantic units of AI workflows — `message`, `tool call`, `resource`, `task`, `context`, `artifact`, and `agent identity` — to first-class subjects of encryption policy and key management.
|
|
13
|
+
|
|
14
|
+
The initial product form is open-source/self-hosted security infrastructure, not SaaS. Users attach Haechi to their AI applications as a library, CLI, sidecar proxy, or MCP wrapper, and must be able to swap out the encryption scheme, policy evaluation, privacy filtering, and audit store to fit their own environment.
|
|
15
|
+
|
|
16
|
+
## 2. Background
|
|
17
|
+
|
|
18
|
+
Standard TLS protects the transport channel between client and server. In LLM/agent systems, however, plaintext exposure recurs at the following points:
|
|
19
|
+
|
|
20
|
+
- LLM gateways, prompt routers, and observability pipelines
|
|
21
|
+
- JSON-RPC messages between MCP clients and servers
|
|
22
|
+
- MCP tool inputs/outputs, resource content, and prompt templates
|
|
23
|
+
- RAG retrieval snippets and vector metadata
|
|
24
|
+
- A2A agent messages, task state, and artifacts
|
|
25
|
+
- gRPC streaming chunks and metadata
|
|
26
|
+
- Agent tool-call logs, traces, and replay records
|
|
27
|
+
- Prompt/context transformation points before and after model provider transmission
|
|
28
|
+
|
|
29
|
+
Haechi is the layer that encrypts, tokenizes, redacts, evaluates permissions, and audits these AI-native data units based on policy.
|
|
30
|
+
|
|
31
|
+
Privacy filtering is a core capability of Haechi. Encryption protects data, but the moment it is exposed in plaintext to a model or tool, separate controls are required. Haechi detects PII in prompts, contexts, MCP tool inputs/outputs, resources, retrieval snippets, and generated artifacts, then handles each finding with one of: `allow`, `redact`, `mask`, `tokenize`, `encrypt`, `block`, or `human-review`.
|
|
32
|
+
|
|
33
|
+
## 3. Product Positioning
|
|
34
|
+
|
|
35
|
+
Haechi does not replace general-purpose security solutions, LLM gateways, MCP frameworks, or agent frameworks. It is an encryption and context protection module that augments existing AI/LLM/MCP-targeted solutions.
|
|
36
|
+
|
|
37
|
+
Commercialization and a SaaS control plane are not initial goals. The initial positioning is: "a small but verifiable OSS core + swappable reference engines + deployment-oriented AI/MCP examples." The default implementation Haechi ships is a reference, not a prescription — users must be able to inject their own implementations through boundaries such as `CryptoProvider`, `PolicyEngine`, `FilterEngine`, `KeyProvider`, and `AuditSink`.
|
|
38
|
+
|
|
39
|
+
| Target Solution | Integration Approach |
|
|
40
|
+
|---|---|
|
|
41
|
+
| LLM gateway | OpenAI-compatible/Anthropic-compatible HTTP adapter or middleware |
|
|
42
|
+
| MCP host/client | MCP client proxy, SDK wrapper, policy interceptor |
|
|
43
|
+
| MCP server | tool/resource/prompt response encryption wrapper |
|
|
44
|
+
| Agent runtime | task/context/artifact scoped encryption |
|
|
45
|
+
| A2A server/client | AgentCard verification, message/task/artifact encryption adapter |
|
|
46
|
+
| gRPC AI service | protobuf field encryption, streaming message protection |
|
|
47
|
+
| RAG pipeline | retrieval snippet, source metadata, artifact encryption |
|
|
48
|
+
| Observability platform | prompt/tool/result redaction, sealed audit events |
|
|
49
|
+
|
|
50
|
+
## 4. Key Differentiators
|
|
51
|
+
|
|
52
|
+
- **AI semantic unit protection**: prompt, system message, tool args, tool result, MCP resource, and A2A artifact are treated as distinct protection subjects.
|
|
53
|
+
- **Context-bound encryption**: tenant, user, agent, model, task, context, tool, and resource URI are included in AAD and decryption authorization evaluation.
|
|
54
|
+
- **Policy before model**: policy determines what information may be exposed in plaintext to a model.
|
|
55
|
+
- **Selective reveal**: only the portions a model strictly needs to see are exposed in plaintext; the rest is kept tokenized or as ciphertext.
|
|
56
|
+
- **MCP/A2A native**: JSON-RPC id, method, session id, task id, artifact id, AgentCard, and streaming events are used as policy context.
|
|
57
|
+
- **Observability-safe**: prompts and tool outputs are not retained in plaintext in logs, traces, metrics, or replay artifacts.
|
|
58
|
+
- **Privacy filtering first**: PII is detected and policy is applied before data is passed to a model, agent, tool, or log.
|
|
59
|
+
- **Easy adoption**: attachable to existing AI applications with minimal changes via proxy, middleware, SDK wrapper, sidecar, or config preset.
|
|
60
|
+
|
|
61
|
+
## 5. Non-Goals
|
|
62
|
+
|
|
63
|
+
- General-purpose cryptography that enables LLMs to directly understand ciphertext is not a goal.
|
|
64
|
+
- Fully homomorphic encryption-based LLM inference is out of MVP scope.
|
|
65
|
+
- End-to-end invisibility to all external LLM providers is not claimed.
|
|
66
|
+
- Complete prevention of prompt injection is not claimed.
|
|
67
|
+
- MCP or A2A protocols themselves are not replaced.
|
|
68
|
+
- The initial version does not provide hosted SaaS, multi-tenant control planes, billing, SLAs, or commercial compliance packs.
|
|
69
|
+
- No novel cryptographic primitives are invented. Validated standards and libraries are composed, and implementation boundaries are tested.
|
|
70
|
+
|
|
71
|
+
## 6. User Segments
|
|
72
|
+
|
|
73
|
+
| User Segment | Need |
|
|
74
|
+
|---|---|
|
|
75
|
+
| AI platform security owner | Minimize plaintext exposure of prompts/contexts/tool calls |
|
|
76
|
+
| LLM gateway operator | Per-provider policy, redaction, encryption, and audit |
|
|
77
|
+
| MCP server developer | Protect tool inputs/outputs and resource content |
|
|
78
|
+
| Agent framework developer | Task/context/artifact-level encryption |
|
|
79
|
+
| RAG operator | Protect retrieval snippets and source metadata |
|
|
80
|
+
| Compliance/audit officer | Track who exposed which context to which model/agent/tool |
|
|
81
|
+
| Privacy officer | Filter and control the exposure scope of PII, unique identifiers, and sensitive data before AI processing |
|
|
82
|
+
| Open-source adopter | Reference the default implementation while easily replacing crypto, policy, filtering, and audit components |
|
|
83
|
+
| OSS contributor/reviewer | Verify a project with proven security design, testing, and documentation quality even within a narrow scope |
|
|
84
|
+
|
|
85
|
+
## 7. Business Requirements
|
|
86
|
+
|
|
87
|
+
| ID | Requirement | Priority | Verification |
|
|
88
|
+
|---|---|---:|---|
|
|
89
|
+
| BR-AI-001 | The product must be delivered as an encryption module that can be added to AI/LLM/MCP-targeted solutions. | Must | PoC |
|
|
90
|
+
| BR-AI-002 | The product must reduce plaintext exposure points for prompts, contexts, tool calls, resources, and artifacts. | Must | threat model |
|
|
91
|
+
| BR-AI-003 | The product must provide an adapter strategy that covers both MCP stdio and Streamable HTTP. | Must | MCP PoC |
|
|
92
|
+
| BR-AI-004 | The product should support gRPC streaming and A2A message/task/artifact protection. | Should | protocol PoC |
|
|
93
|
+
| BR-AI-005 | The product must enforce policy-based control over the plaintext exposure scope when using external LLM providers. | Must | policy test |
|
|
94
|
+
| BR-AI-006 | The product must remove or seal AI sensitive data from logs, traces, replays, and metrics. | Must | observability test |
|
|
95
|
+
| BR-AI-007 | The product must support KMS/HSM/Vault-based key management and per-tenant/agent/task key separation. | Must | key test |
|
|
96
|
+
| BR-AI-008 | The product must detect PII, unique identifiers, sensitive data, credentials, and secrets, and apply policy before exposing them to models/tools/agents. | Must | privacy filtering test |
|
|
97
|
+
| BR-AI-009 | The product should support detection rules adapted to the Korean privacy environment and customer-specific custom entity rules. | Should | Korean PII fixture test |
|
|
98
|
+
| BR-AI-010 | The product must support selecting privacy regulatory profiles for major markets — Korea, EU/UK, US, Japan, Singapore, Canada, and Brazil — as policy. | Must | regional profile test |
|
|
99
|
+
| BR-AI-011 | The product must include cross-border transfer, data residency, subprocessors, and model provider region in the policy decision context. | Must | transfer policy test |
|
|
100
|
+
| BR-AI-012 | The product should produce decision records and data flow evidence sufficient to support data subject rights responses, audits, DPIA/PIA, and DSAR exports. | Should | audit evidence review |
|
|
101
|
+
| BR-AI-013 | The product must support per-customer/tenant custom filtering rules, dictionaries, classifiers, and action overrides. | Must | custom filter test |
|
|
102
|
+
| BR-AI-014 | The product must provide AAD canonicalization, nonce/replay defense, key lifecycle, and signed policy distribution as first-class cryptographic security requirements. | Must | crypto negative test |
|
|
103
|
+
| BR-AI-015 | The product must define security contracts covering transport, auth, lifecycle, and metadata scrubbing for each MCP, A2A, gRPC, and LLM gateway adapter. | Must | protocol contract test |
|
|
104
|
+
| BR-AI-016 | The product must be usable as a library, CLI, local proxy, or self-hosted sidecar without depending on hosted SaaS, and must explicitly state key custody and telemetry boundaries. | Must | deployment review |
|
|
105
|
+
| BR-AI-017 | The product must prioritize OSS trust artifacts over commercial evidence packs: `SECURITY.md`, threat model, conformance tests, SBOM, signed release artifacts, and security test results. | Must | OSS trust review |
|
|
106
|
+
| BR-AI-018 | The product must verify plaintext leak, policy conflict, KMS fault, replay, region-deny, and custom DSL bypass as build-blocking security tests. | Must | CI gate test |
|
|
107
|
+
| BR-AI-019 | The product must separate encryption, key management, policy evaluation, privacy filtering, token vault, audit, and protocol adapters into swappable provider interfaces. | Must | plugin boundary review |
|
|
108
|
+
| BR-AI-020 | The product must provide a default reference implementation while offering dependency injection, plugin manifests, and compatibility contracts so users can inject their own implementations. | Must | plugin conformance test |
|
|
109
|
+
| BR-AI-021 | The product must require plugins to declare capabilities such as plaintext access, network egress, file writes, and audit logging, and evaluate them under a fail-closed policy. | Must | plugin security test |
|
|
110
|
+
| BR-AI-022 | The product must apply to existing AI/LLM/MCP solutions with low change cost, targeting a 5-minute local demo, 30-minute MCP/LLM PoC, and same-day custom filter PoC. | Must | adoption test |
|
|
111
|
+
| BR-AI-023 | The product must lower the adoption barrier through `init`, preset policies, dry-run, report-only mode, and copy-paste middleware examples while maintaining secure defaults. | Must | quickstart review |
|
|
112
|
+
|
|
113
|
+
## 8. Product Requirements
|
|
114
|
+
|
|
115
|
+
| ID | Requirement | Priority |
|
|
116
|
+
|---|---|---:|
|
|
117
|
+
| PRD-AI-001 | The product must support per-role encryption, redaction, and tokenization policies for prompt messages. | Must |
|
|
118
|
+
| PRD-AI-002 | The product must support per-method policies for MCP JSON-RPC. | Must |
|
|
119
|
+
| PRD-AI-003 | The product must classify MCP tool inputs/outputs, resource content, and prompt templates as protection subjects. | Must |
|
|
120
|
+
| PRD-AI-004 | The product should include A2A agent id, task id, context id, and artifact id in encryption AAD and decryption authorization evaluation. | Should |
|
|
121
|
+
| PRD-AI-005 | The product should have an architecture capable of supporting both gRPC protobuf field encryption and opaque message encryption. | Should |
|
|
122
|
+
| PRD-AI-006 | The product should support per-chunk nonces and stream/session binding for streaming chunks. | Should |
|
|
123
|
+
| PRD-AI-007 | The product must produce a policy decision record before sending plaintext to a model provider. | Must |
|
|
124
|
+
| PRD-AI-008 | The product must apply redaction by default to prompt/tool/resource/artifact logs. | Must |
|
|
125
|
+
| PRD-AI-009 | The product must distinguish between customer-managed keys and provider-managed keys. | Must |
|
|
126
|
+
| PRD-AI-010 | The product should support trust verification and allowlisting for MCP/A2A discovery metadata. | Should |
|
|
127
|
+
| PRD-AI-011 | The product must provide a privacy filtering pipeline that combines deterministic rules, checksum validation, dictionary/NER, and pluggable classifiers. | Must |
|
|
128
|
+
| PRD-AI-012 | The product must include as default detection targets: resident registration numbers, alien registration numbers, passport numbers, driver's license numbers, mobile phone numbers, email addresses, physical addresses, bank account numbers, card numbers, health information, biometric data, authentication credentials, and API keys/secrets. | Must |
|
|
129
|
+
| PRD-AI-013 | The product must support specifying the handling action for each detected PII finding as one of: `redact`, `mask`, `tokenize`, `encrypt`, `block`, or `human-review`. | Must |
|
|
130
|
+
| PRD-AI-014 | The product must support both pre-filter (before model invocation) and post-filter (after model/tool response). | Must |
|
|
131
|
+
| PRD-AI-015 | The product must not retain the original text of filtered findings in logs; it must audit only entity type, confidence, rule id, action, and decision id. | Must |
|
|
132
|
+
| PRD-AI-016 | The product must support switching the detection catalog, default action, transfer rules, retention rules, and audit fields through regional privacy profiles. | Must |
|
|
133
|
+
| PRD-AI-017 | The product must be able to express GDPR/UK GDPR requirements for personal data, special category data, pseudonymisation, and international transfer as policy items. | Must |
|
|
134
|
+
| PRD-AI-018 | The product should be able to express CCPA/CPRA requirements for sensitive personal information and limit-use as policy items. | Should |
|
|
135
|
+
| PRD-AI-019 | The product should apply detection, redaction, tokenization, and logging-prohibition policies to HIPAA PHI and PCI cardholder data as separate sector profiles. | Should |
|
|
136
|
+
| PRD-AI-020 | The product must be able to enforce per-tenant data residency and model provider region allowlists in global deployments. | Must |
|
|
137
|
+
| PRD-AI-021 | The product must provide a custom filter DSL combining regex, checksum validators, keyword dictionaries, deny/allow lists, JSONPath/protobuf path, and semantic classifiers. | Must |
|
|
138
|
+
| PRD-AI-022 | The product must support a draft, validate, test, approve, publish, and rollback lifecycle for custom filter rules. | Must |
|
|
139
|
+
| PRD-AI-023 | The product must apply a clear priority order on custom filter rule conflicts: global profile, sector profile, tenant rule, app rule, emergency rule. | Must |
|
|
140
|
+
| PRD-AI-024 | The product should encrypt customer-supplied custom dictionaries and fixtures at rest and enforce auditable access control. | Should |
|
|
141
|
+
| PRD-AI-025 | The product should support deploying custom classifier plugins as one of: local-only, customer-managed endpoint, or external endpoint. | Should |
|
|
142
|
+
| PRD-AI-026 | The product must fix encryption AAD using canonical JSON, Unicode normalization, and tenant/user/agent/model/task/tool/resource/policy version. | Must |
|
|
143
|
+
| PRD-AI-027 | The product must enforce nonce uniqueness, stream sequence integrity, and replay cache across streaming chunks, retries, cancellations, and partial deliveries. | Must |
|
|
144
|
+
| PRD-AI-028 | The product must manage key generation, rotation, rewrap, retirement, destruction evidence, and backup/restore drills as a key lifecycle. | Must |
|
|
145
|
+
| PRD-AI-029 | The product must support token vault retention, deletion, DSAR export, re-identification approval, and access audit. | Must |
|
|
146
|
+
| PRD-AI-030 | The product must support policy bundle signing, version pinning, emergency block, fail-closed validation, and stale policy rejection. | Must |
|
|
147
|
+
| PRD-AI-031 | The product must enforce MCP authorization, token passthrough prohibition, per-client consent, stdio credential handling, and protocol version negotiation. | Must |
|
|
148
|
+
| PRD-AI-032 | The product should verify A2A AgentCard signatures, authenticated extended cards, transport parity, and push notification security. | Should |
|
|
149
|
+
| PRD-AI-033 | The product must remove original sensitive data from OpenTelemetry baggage, span attributes, metric labels, exceptions, crash dumps, and replay artifacts. | Must |
|
|
150
|
+
| PRD-AI-034 | The product should have a provider-neutral LLM message schema and provider adapter mapping. | Should |
|
|
151
|
+
| PRD-AI-035 | The product should support RAG/vector namespace, embedding/source metadata, citation, and index deletion propagation policies. | Should |
|
|
152
|
+
| PRD-AI-036 | The product should classify agent memory as ephemeral or durable and support TTL, purge, export, and cross-task recall blocking. | Should |
|
|
153
|
+
| PRD-AI-037 | The product must provide per-tenant config store, audit sink, quota, admin RBAC, and blast-radius limits. | Must |
|
|
154
|
+
| PRD-AI-038 | The product should provide SBOM, artifact signing, provenance, dependency vulnerability policy, and classifier/plugin trust policy. | Should |
|
|
155
|
+
| PRD-AI-039 | The product must provide envelope encryption, decrypt, rewrap, and key id resolution as swappable operations through the `CryptoProvider` interface. | Must |
|
|
156
|
+
| PRD-AI-040 | The product must allow connecting local key, Vault, KMS, HSM, and test key providers under the same contract through the `KeyProvider` interface. | Must |
|
|
157
|
+
| PRD-AI-041 | The product must allow connecting CEL, OPA/Rego, and user-supplied policy engines — in addition to JSON/YAML reference policies — through the `PolicyEngine` interface. | Must |
|
|
158
|
+
| PRD-AI-042 | The product must allow replacing the rule/checksum/dictionary-based reference filter and user-supplied classifiers through the `FilterEngine` interface. | Must |
|
|
159
|
+
| PRD-AI-043 | The product should allow replacing local encrypted vault, DB-backed vault, and external vault through the `TokenVault` interface. | Should |
|
|
160
|
+
| PRD-AI-044 | The product must allow replacing JSONL, OpenTelemetry-safe exporter, SIEM webhook, and custom sinks through the `AuditSink` interface. | Must |
|
|
161
|
+
| PRD-AI-045 | The product must ensure that MCP, LLM HTTP, gRPC, and A2A adapters all use the same protect/reveal pipeline through the `ProtocolAdapter` interface. | Must |
|
|
162
|
+
| PRD-AI-046 | The product must provide golden fixtures, negative fixtures, capability manifests, and compatibility version tests for all providers/plugins. | Must |
|
|
163
|
+
| PRD-AI-047 | The product must provide a local proxy mode that requires minimal changes to existing code. Users must be able to reroute LLM/MCP requests by specifying only a target base URL and a policy file. | Must |
|
|
164
|
+
| PRD-AI-048 | The product must be applicable to Node and Python AI applications with SDK wrapper/middleware examples of ten lines or fewer. | Must |
|
|
165
|
+
| PRD-AI-049 | The product must generate a sample policy, local key, audit path, and MCP/LLM presets via `haechi init` or an equivalent CLI command. | Must |
|
|
166
|
+
| PRD-AI-050 | The product must provide a `dry-run` or `report-only` mode to inspect which prompts/tools/resources would be detected before actual blocking or encryption takes effect. | Must |
|
|
167
|
+
| PRD-AI-051 | The product must provide the following default presets: `mcp-basic`, `llm-redact`, `korean-pii`, `secrets-only`, `local-only`, `strict-block`. | Must |
|
|
168
|
+
| PRD-AI-052 | The product should provide a path for users to swap `CryptoProvider`, `PolicyEngine`, `FilterEngine`, and `AuditSink` from config without code changes. | Should |
|
|
169
|
+
| PRD-AI-053 | The product must prefer blocking requests over leaking plaintext on application failure, and must explain the cause and remediation in development mode without including plaintext data. | Must |
|
|
170
|
+
|
|
171
|
+
## 9. MVP Scope
|
|
172
|
+
|
|
173
|
+
The MVP starts narrow.
|
|
174
|
+
|
|
175
|
+
The actual 0.1 implementation scope is governed by `docs/current/mvp-0.1-implementation-scope.md`. Among the items below, the Python SDK, Vault/KMS adapter, MCP stdio wrapper, and RAG sample may be deferred beyond 0.1.
|
|
176
|
+
|
|
177
|
+
Included:
|
|
178
|
+
|
|
179
|
+
- TypeScript/Node SDK
|
|
180
|
+
- Python SDK
|
|
181
|
+
- core provider interface package
|
|
182
|
+
- plugin manifest schema
|
|
183
|
+
- provider conformance test harness
|
|
184
|
+
- local CLI demo
|
|
185
|
+
- one-command `init` quickstart
|
|
186
|
+
- dry-run/report-only mode
|
|
187
|
+
- copy-paste Node/Python middleware examples
|
|
188
|
+
- MCP/LLM preset policy files
|
|
189
|
+
- MCP Streamable HTTP proxy
|
|
190
|
+
- MCP stdio wrapper
|
|
191
|
+
- OpenAI-compatible HTTP request/response adapter
|
|
192
|
+
- prompt/tool/resource redaction and envelope encryption
|
|
193
|
+
- privacy filtering pipeline
|
|
194
|
+
- Korean PII default detection rules
|
|
195
|
+
- one of: Vault or AWS KMS adapter
|
|
196
|
+
- local software key provider
|
|
197
|
+
- JSON policy file
|
|
198
|
+
- audit event JSON Lines
|
|
199
|
+
- MCP tool-call sample
|
|
200
|
+
- RAG snippet protection sample
|
|
201
|
+
- reference `CryptoProvider`, `PolicyEngine`, `FilterEngine`, `KeyProvider`, `AuditSink`
|
|
202
|
+
|
|
203
|
+
Excluded from MVP:
|
|
204
|
+
|
|
205
|
+
- Fully homomorphic encryption or ciphertext LLM inference
|
|
206
|
+
- Native SDK support for all LLM providers
|
|
207
|
+
- Built-in KCMVP provider
|
|
208
|
+
- Full A2A server implementation
|
|
209
|
+
- gRPC bidirectional streaming production adapter
|
|
210
|
+
- GUI management console
|
|
211
|
+
- Hosted SaaS control plane
|
|
212
|
+
- Billing, tenant admin portal, SLA
|
|
213
|
+
- SOC 2/ISO commercial evidence pack
|
|
214
|
+
|
|
215
|
+
## 10. Core Security Principles
|
|
216
|
+
|
|
217
|
+
- Separate values the model must process from values the model does not need to see.
|
|
218
|
+
- Classify PII before exposing it to a model; apply default blocking or tokenization when the purpose of exposure is not clear.
|
|
219
|
+
- Explicitly state that data sent in plaintext to a model provider can no longer be guaranteed invisible by Haechi alone.
|
|
220
|
+
- Treat tool-call and resource results as sensitive by default.
|
|
221
|
+
- Include agent/task/context boundaries in AAD and decryption authorization.
|
|
222
|
+
- Treat the observability pipeline as a first-class security boundary of the product.
|
|
223
|
+
- Prompt injection defense and encryption are separate controls; neither substitutes for the other.
|
|
224
|
+
- Swappable providers/plugins are trust boundaries. Expose and test capabilities such as plaintext access, network egress, file writes, and audit manipulation.
|
|
225
|
+
- The reference implementation must be replaceable by users, but conformance tests and security negative tests remain as a fixed baseline that is not replaced.
|
|
226
|
+
|
|
227
|
+
## 11. Open Questions
|
|
228
|
+
|
|
229
|
+
- Decide whether the MCP adapter should be proxy-first or SDK wrapper-first.
|
|
230
|
+
- Decide whether to use an OpenAI-compatible API as the primary LLM adapter or to define a provider-agnostic schema first.
|
|
231
|
+
- Decide whether to protect embeddings themselves in RAG vector search or focus on protecting source text and metadata.
|
|
232
|
+
- Decide whether A2A remains at the adapter level or evolves into a full protocol gateway.
|
|
233
|
+
- Decide whether to include confidential computing/TEE in the secondary roadmap.
|
|
234
|
+
- Decide whether an ML/LLM classifier used for PII detection may receive plaintext PII at that classifier itself.
|
|
235
|
+
- Decide whether high-risk identifiers such as resident registration numbers default to block, or whether tokenization may be permitted under customer policy.
|
|
236
|
+
- Decide whether the product supports EU/UK data transfer mechanisms (SCC/IDTA) as evidence only or enforces them as policy.
|
|
237
|
+
- Decide whether HIPAA/PCI sector profiles are included in the MVP or deferred as later examples.
|
|
238
|
+
- Decide whether the custom filter DSL uses a product-specific syntax or partially adopts an existing policy language such as OPA/Rego or CEL.
|
|
239
|
+
- Decide whether external endpoint calls by custom classifier plugins default to prohibiting PII transmission or require customer opt-in.
|
|
240
|
+
- Decide whether to stabilize the provider/plugin API TypeScript-first and then align Python, or to define a language-neutral IDL first.
|
|
241
|
+
- Decide whether the open-source license is Apache-2.0 or MIT.
|
|
242
|
+
|
|
243
|
+
## 12. References
|
|
244
|
+
|
|
245
|
+
- Model Context Protocol Specification, latest: https://modelcontextprotocol.io/specification/
|
|
246
|
+
- Model Context Protocol Authorization: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
|
|
247
|
+
- Model Context Protocol Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
|
|
248
|
+
- Model Context Protocol official repository: https://github.com/modelcontextprotocol/modelcontextprotocol
|
|
249
|
+
- NSA MCP Security Design Considerations: https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf
|
|
250
|
+
- NSA/Five Eyes Careful Adoption of Agentic AI Services: https://media.defense.gov/2026/Apr/30/2003922823/-1/-1/0/CAREFUL%20ADOPTION%20OF%20AGENTIC%20AI%20SERVICES_FINAL.PDF
|
|
251
|
+
- A2A Agent2Agent Protocol: https://a2a-protocol.org/latest/specification/
|
|
252
|
+
- gRPC Core Concepts: https://grpc.io/docs/what-is-grpc/core-concepts/
|
|
253
|
+
- Korean Personal Information Safety Measures Standard: https://law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000192069&chrClsCd=010201
|
|
254
|
+
- KISA Cryptography FAQ: https://seed.kisa.or.kr/kisa/bbs/faq.do
|
|
255
|
+
- European Commission GDPR overview: https://commission.europa.eu/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en
|
|
256
|
+
- European Commission Standard Contractual Clauses: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
|
|
257
|
+
- California CCPA: https://www.oag.ca.gov/privacy/ccpa
|
|
258
|
+
- HHS HIPAA Privacy Rule: https://www.hhs.gov/hipaa/for-professionals/privacy/index.html
|
|
259
|
+
- NIST Privacy Framework: https://www.nist.gov/privacy-framework
|
|
260
|
+
- RFC 8446, TLS 1.3
|
|
261
|
+
- RFC 7516, JSON Web Encryption
|
|
262
|
+
- RFC 9180, Hybrid Public Key Encryption
|
|
@@ -0,0 +1,307 @@
|
|
|
1
|
+
# 개인정보 필터링 정책 초안
|
|
2
|
+
|
|
3
|
+
- 문서 상태: Draft 0.1
|
|
4
|
+
- 작성일: 2026-06-08
|
|
5
|
+
- 관련 제품: Haechi
|
|
6
|
+
|
|
7
|
+
## 1. 목적
|
|
8
|
+
|
|
9
|
+
본 문서는 AI/LLM/MCP 환경에서 개인정보와 고위험 민감 데이터를 모델, tool, agent, 로그, trace, replay artifact로 전달하기 전에 탐지하고 처리하는 정책 초안을 정의한다.
|
|
10
|
+
|
|
11
|
+
개인정보 필터링은 암호화의 대체물이 아니다. 필터링은 평문 공개 여부를 결정하고, 암호화는 저장·전송·권한 경계를 보호한다. Haechi는 두 기능을 함께 적용한다.
|
|
12
|
+
|
|
13
|
+
## 2. 필터링 지점
|
|
14
|
+
|
|
15
|
+
| 지점 | 설명 | 기본 정책 |
|
|
16
|
+
|---|---|---|
|
|
17
|
+
| Pre-model | LLM provider 호출 전 prompt/message 필터링 | Must |
|
|
18
|
+
| Post-model | LLM 응답을 사용자, agent, tool에 전달하기 전 필터링 | Must |
|
|
19
|
+
| MCP tool input | MCP tools/call arguments 필터링 | Must |
|
|
20
|
+
| MCP tool output | tool result와 resource content 필터링 | Must |
|
|
21
|
+
| RAG input | retrieval query, snippet, source metadata 필터링 | Should |
|
|
22
|
+
| A2A message | agent message, task, artifact 필터링 | Should |
|
|
23
|
+
| Observability | log, trace, replay, metric label 필터링 | Must |
|
|
24
|
+
|
|
25
|
+
## 3. 기본 탐지 카탈로그
|
|
26
|
+
|
|
27
|
+
| 분류 | 예시 | 기본 액션 |
|
|
28
|
+
|---|---|---|
|
|
29
|
+
| 고유식별정보 | 주민등록번호, 외국인등록번호, 여권번호, 운전면허번호 | block 또는 tokenize |
|
|
30
|
+
| 민감정보 | 건강정보, 생체정보, 유전정보, 범죄경력, 정치/노조/종교 관련 정보 | block 또는 human-review |
|
|
31
|
+
| 연락처 | 휴대전화번호, 전화번호, 이메일, 주소 | mask 또는 tokenize |
|
|
32
|
+
| 금융정보 | 계좌번호, 카드번호, 카드 유효기간, CVC 유사값 | tokenize 또는 block |
|
|
33
|
+
| 인증정보 | 비밀번호, access token, refresh token, API key, private key | block |
|
|
34
|
+
| 고객 데이터 | 고객번호, 계약번호, 주문번호, 내부 식별자 | tokenize 또는 encrypt |
|
|
35
|
+
| AI 특화 민감정보 | prompt 내 secret, tool output 내 개인정보, RAG snippet 내 개인정보 | redact, tokenize, encrypt |
|
|
36
|
+
|
|
37
|
+
## 4. 글로벌 규제 프로파일
|
|
38
|
+
|
|
39
|
+
지역별 기본 프로파일은 탐지 카탈로그, 기본 액션, 전송 제한, 감사 필드, 보존 정책을 바꾼다. 이 표는 제품 정책 설계를 위한 출발점이며 법률 자문을 대체하지 않는다.
|
|
40
|
+
|
|
41
|
+
| Profile | 주요 기준 | 기본 강화 항목 |
|
|
42
|
+
|---|---|---|
|
|
43
|
+
| KR-PIPA | 개인정보, 고유식별정보, 민감정보, 안전성 확보조치 | 고유식별정보 block/tokenize, 암호키 관리, 접속기록 |
|
|
44
|
+
| EU-GDPR | personal data, special categories, pseudonymisation, data minimisation, international transfer | special category 기본 block/human-review, SCC/adequacy evidence, DPIA evidence |
|
|
45
|
+
| UK-GDPR | UK GDPR, IDTA/Addendum, special category data | UK transfer mechanism evidence, special category 강화 |
|
|
46
|
+
| US-CCPA-CPRA | personal information, sensitive personal information, limit use/disclosure | SPI limit-use flag, consumer request evidence |
|
|
47
|
+
| US-HIPAA | PHI, covered entity/business associate, de-identification | PHI default block/tokenize, Safe Harbor style identifier catalog, BAA evidence |
|
|
48
|
+
| PCI-DSS | cardholder data, sensitive authentication data | PAN tokenize/mask, CVC block, payment data logging 금지 |
|
|
49
|
+
| JP-APPI | personal information, special care-required personal information, anonymized/pseudonymized information | special care-required 정보 human-review, cross-border consent/evidence |
|
|
50
|
+
| SG-PDPA | consent, purpose limitation, protection, retention, transfer limitation | purpose binding, transfer limitation evidence |
|
|
51
|
+
| CA-PIPEDA | consent, limiting collection/use/disclosure, safeguards, cross-border handling | consent/purpose evidence, safeguard audit |
|
|
52
|
+
| BR-LGPD | personal data, sensitive personal data, international transfer | sensitive data 강화, ANPD transfer mechanism evidence |
|
|
53
|
+
|
|
54
|
+
## 5. 글로벌 정책 결정 context
|
|
55
|
+
|
|
56
|
+
| Context | 설명 |
|
|
57
|
+
|---|---|
|
|
58
|
+
| data_subject_region | 정보주체의 추정 또는 명시 지역 |
|
|
59
|
+
| controller_region | 고객/controller 지역 |
|
|
60
|
+
| processor_region | Haechi/processor 처리 지역 |
|
|
61
|
+
| model_provider_region | LLM provider 처리 지역 |
|
|
62
|
+
| transfer_mechanism | SCC, IDTA, adequacy, BCR, consent, local-only 등 |
|
|
63
|
+
| sector_profile | healthcare, payment, finance, education, public sector 등 |
|
|
64
|
+
| lawful_basis_or_purpose | 처리 목적 또는 법적 근거를 표현하는 고객 정의 값 |
|
|
65
|
+
| residency_policy | local-only, region-locked, allowed-regions |
|
|
66
|
+
| retention_policy | audit와 token vault 보존 정책 |
|
|
67
|
+
|
|
68
|
+
## 6. 탐지 방식
|
|
69
|
+
|
|
70
|
+
| 방식 | 적용 대상 | 요구사항 |
|
|
71
|
+
|---|---|---|
|
|
72
|
+
| Deterministic rule | 주민등록번호, 카드번호, 이메일, 전화번호, API key | 규칙 ID와 버전을 관리해야 한다. |
|
|
73
|
+
| Checksum validation | 주민등록번호 후보, 카드번호 후보 | 유효성 검증 실패 후보는 confidence를 낮춘다. |
|
|
74
|
+
| Dictionary | 조직명, 내부 시스템명, 금칙어 | tenant별 dictionary를 지원한다. |
|
|
75
|
+
| NER/classifier | 이름, 주소, 의료/건강 문맥, 민감 추론 | local-first를 기본으로 하고 외부 전송 시 별도 동의/정책이 필요하다. |
|
|
76
|
+
| Custom entity rule | 고객별 식별자, 계약번호, 티켓번호 | policy에서 schema와 action을 정의한다. |
|
|
77
|
+
|
|
78
|
+
## 7. 커스텀 필터링
|
|
79
|
+
|
|
80
|
+
기본 규제 프로파일은 고객 내부 데이터를 충분히 알 수 없다. Haechi는 tenant별 custom filter를 1급 기능으로 제공해야 한다.
|
|
81
|
+
|
|
82
|
+
### 7.1 커스텀 탐지 대상
|
|
83
|
+
|
|
84
|
+
| 대상 | 예시 |
|
|
85
|
+
|---|---|
|
|
86
|
+
| 내부 식별자 | 고객번호, 사번, 멤버십 ID, 계약번호, 주문번호, 티켓번호 |
|
|
87
|
+
| 제품/프로젝트 기밀 | 코드명, 제품 출시명, 내부 roadmap keyword |
|
|
88
|
+
| 사내 시스템 정보 | internal hostname, repository name, table name, service name |
|
|
89
|
+
| 산업 특화 데이터 | 의료 chart id, 보험 증권번호, 송장번호, 계좌 별칭 |
|
|
90
|
+
| AI 특화 데이터 | prompt template secret, tool name, private skill name, vector collection name |
|
|
91
|
+
| 보안정보 | internal API key prefix, service account, private endpoint, secret naming pattern |
|
|
92
|
+
|
|
93
|
+
### 7.2 Custom filter DSL 요구사항
|
|
94
|
+
|
|
95
|
+
| 기능 | 설명 |
|
|
96
|
+
|---|---|
|
|
97
|
+
| regex | 정규식 기반 탐지 |
|
|
98
|
+
| checksum | 고객 정의 checksum 또는 validator 함수 |
|
|
99
|
+
| dictionary | tenant별 단어/구문 사전 |
|
|
100
|
+
| allowlist | 오탐 예외 처리 |
|
|
101
|
+
| denylist | 즉시 차단 대상 |
|
|
102
|
+
| path scope | JSONPath, protobuf field path, MCP method, A2A part type 범위 지정 |
|
|
103
|
+
| context condition | tenant, app, environment, model provider, region, purpose 조건 |
|
|
104
|
+
| action override | 기본 profile action보다 강한 조치 적용 |
|
|
105
|
+
| confidence override | rule별 confidence 계산 또는 고정 |
|
|
106
|
+
| test fixture | positive/negative sample과 expected action |
|
|
107
|
+
|
|
108
|
+
### 7.3 Rule lifecycle
|
|
109
|
+
|
|
110
|
+
| 단계 | 요구사항 |
|
|
111
|
+
|---|---|
|
|
112
|
+
| draft | rule 작성자는 production traffic에 영향을 주지 않고 초안을 만들 수 있어야 한다. |
|
|
113
|
+
| validate | schema, regex safety, catastrophic backtracking, action 충돌을 검사해야 한다. |
|
|
114
|
+
| test | fixture와 shadow traffic으로 false positive/negative를 측정해야 한다. |
|
|
115
|
+
| approve | 고위험 action, 예: block, external classifier, region override는 승인 절차가 필요하다. |
|
|
116
|
+
| publish | versioned rollout과 tenant/app/environment scope가 필요하다. |
|
|
117
|
+
| monitor | hit rate, action rate, override rate를 관측해야 한다. |
|
|
118
|
+
| rollback | 이전 rule version으로 즉시 되돌릴 수 있어야 한다. |
|
|
119
|
+
|
|
120
|
+
### 7.4 우선순위
|
|
121
|
+
|
|
122
|
+
강한 보호가 약한 보호보다 우선한다.
|
|
123
|
+
|
|
124
|
+
1. Emergency global block rule
|
|
125
|
+
2. Legal/regional profile mandatory rule
|
|
126
|
+
3. Sector profile mandatory rule
|
|
127
|
+
4. Tenant custom rule
|
|
128
|
+
5. Application custom rule
|
|
129
|
+
6. Allowlist exception
|
|
130
|
+
7. Default profile rule
|
|
131
|
+
|
|
132
|
+
Allowlist는 고유식별정보, PHI, card security code, secret 같은 hard-block entity를 우회할 수 없어야 한다.
|
|
133
|
+
|
|
134
|
+
### 7.5 커스텀 규칙 예시
|
|
135
|
+
|
|
136
|
+
```yaml
|
|
137
|
+
customRules:
|
|
138
|
+
- id: tenant-contract-id
|
|
139
|
+
version: 3
|
|
140
|
+
owner: privacy-team
|
|
141
|
+
match:
|
|
142
|
+
regex: "\\bCTR-[0-9]{4}-[A-Z0-9]{8}\\b"
|
|
143
|
+
entityType: TENANT_CONTRACT_ID
|
|
144
|
+
scope:
|
|
145
|
+
sources:
|
|
146
|
+
- pre_model
|
|
147
|
+
- mcp_tool_input
|
|
148
|
+
- a2a_artifact
|
|
149
|
+
action: tokenize
|
|
150
|
+
tests:
|
|
151
|
+
positive:
|
|
152
|
+
- input: "계약번호는 CTR-2026-AB12CD34 입니다"
|
|
153
|
+
expectedEntity: TENANT_CONTRACT_ID
|
|
154
|
+
expectedAction: tokenize
|
|
155
|
+
negative:
|
|
156
|
+
- input: "CTR-ABCD는 제품 코드입니다"
|
|
157
|
+
expectedEntity: null
|
|
158
|
+
|
|
159
|
+
- id: internal-project-codename
|
|
160
|
+
version: 1
|
|
161
|
+
match:
|
|
162
|
+
dictionaryRef: dict://tenant-a/project-codenames
|
|
163
|
+
caseSensitive: false
|
|
164
|
+
action: block
|
|
165
|
+
appliesTo:
|
|
166
|
+
modelProviderRegionNotIn:
|
|
167
|
+
- local
|
|
168
|
+
- private-cloud
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
## 8. 처리 액션
|
|
172
|
+
|
|
173
|
+
| 액션 | 의미 |
|
|
174
|
+
|---|---|
|
|
175
|
+
| allow | 탐지 결과를 허용한다. audit event는 남긴다. |
|
|
176
|
+
| mask | 일부 문자만 유지하고 나머지를 마스킹한다. |
|
|
177
|
+
| redact | 값을 제거하고 placeholder로 대체한다. |
|
|
178
|
+
| tokenize | 복원 가능한 token으로 대체한다. 복원은 권한 평가 후 수행한다. |
|
|
179
|
+
| encrypt | envelope ciphertext로 대체한다. |
|
|
180
|
+
| block | 요청, 응답, tool-call 또는 artifact 전달을 차단한다. |
|
|
181
|
+
| human-review | 승인 workflow로 보낸다. 자동 전달하지 않는다. |
|
|
182
|
+
| region-deny | 지역/전송 정책 위반으로 차단한다. |
|
|
183
|
+
| local-only | 외부 provider 호출 없이 로컬 처리만 허용한다. |
|
|
184
|
+
|
|
185
|
+
## 9. 정책 예시
|
|
186
|
+
|
|
187
|
+
```yaml
|
|
188
|
+
profiles:
|
|
189
|
+
active:
|
|
190
|
+
- KR-PIPA
|
|
191
|
+
- EU-GDPR
|
|
192
|
+
- US-CCPA-CPRA
|
|
193
|
+
|
|
194
|
+
rules:
|
|
195
|
+
- id: kr-unique-id-default
|
|
196
|
+
match:
|
|
197
|
+
entityTypes:
|
|
198
|
+
- KR_RRN
|
|
199
|
+
- KR_ALIEN_REG_NO
|
|
200
|
+
- PASSPORT_NO
|
|
201
|
+
- DRIVER_LICENSE_NO
|
|
202
|
+
action: block
|
|
203
|
+
appliesTo:
|
|
204
|
+
- pre_model
|
|
205
|
+
- mcp_tool_input
|
|
206
|
+
- observability
|
|
207
|
+
|
|
208
|
+
- id: contact-info-tokenize
|
|
209
|
+
match:
|
|
210
|
+
entityTypes:
|
|
211
|
+
- EMAIL
|
|
212
|
+
- PHONE
|
|
213
|
+
- ADDRESS
|
|
214
|
+
action: tokenize
|
|
215
|
+
reveal:
|
|
216
|
+
allowedPurposes:
|
|
217
|
+
- customer_support
|
|
218
|
+
requireAudit: true
|
|
219
|
+
|
|
220
|
+
- id: tool-output-redact
|
|
221
|
+
match:
|
|
222
|
+
source: mcp_tool_output
|
|
223
|
+
minConfidence: 0.65
|
|
224
|
+
action: redact
|
|
225
|
+
|
|
226
|
+
- id: eu-special-category-transfer-guard
|
|
227
|
+
match:
|
|
228
|
+
profiles:
|
|
229
|
+
- EU-GDPR
|
|
230
|
+
entityTypes:
|
|
231
|
+
- HEALTH_DATA
|
|
232
|
+
- BIOMETRIC_ID
|
|
233
|
+
- POLITICAL_OPINION
|
|
234
|
+
- UNION_MEMBERSHIP
|
|
235
|
+
destination:
|
|
236
|
+
modelProviderRegionNotIn:
|
|
237
|
+
- EU
|
|
238
|
+
- EEA
|
|
239
|
+
action: region-deny
|
|
240
|
+
require:
|
|
241
|
+
transferMechanism:
|
|
242
|
+
- adequacy
|
|
243
|
+
- SCC
|
|
244
|
+
- BCR
|
|
245
|
+
```
|
|
246
|
+
|
|
247
|
+
## 10. 감사 이벤트
|
|
248
|
+
|
|
249
|
+
감사 이벤트는 원문을 포함하지 않아야 한다.
|
|
250
|
+
|
|
251
|
+
| 필드 | 설명 |
|
|
252
|
+
|---|---|
|
|
253
|
+
| decision_id | 정책 결정 ID |
|
|
254
|
+
| entity_type | 탐지된 entity type |
|
|
255
|
+
| rule_id | 적용된 rule |
|
|
256
|
+
| confidence | 탐지 confidence |
|
|
257
|
+
| action | 적용한 처리 |
|
|
258
|
+
| source | pre_model, mcp_tool_input 등 |
|
|
259
|
+
| tenant_id_hash | tenant 식별자 hash |
|
|
260
|
+
| agent_id_hash | agent 식별자 hash |
|
|
261
|
+
| request_id | correlation id |
|
|
262
|
+
| profile | 적용된 regional/sector profile |
|
|
263
|
+
| transfer_mechanism | 적용된 전송 메커니즘 |
|
|
264
|
+
| residency_decision | 지역 정책 결정 |
|
|
265
|
+
| custom_rule_id | 커스텀 규칙이 적용된 경우 rule id |
|
|
266
|
+
| custom_rule_version | 커스텀 규칙 버전 |
|
|
267
|
+
|
|
268
|
+
## 11. 테스트 기준
|
|
269
|
+
|
|
270
|
+
- 한국 개인정보 fixture를 유지한다.
|
|
271
|
+
- EU special category, US sensitive personal information, HIPAA PHI, PCI card data, Japan/Singapore/Brazil/Canada fixture를 유지한다.
|
|
272
|
+
- 주민등록번호, 외국인등록번호, 카드번호는 checksum positive/negative fixture를 모두 포함한다.
|
|
273
|
+
- custom rule별 positive/negative fixture를 필수로 요구한다.
|
|
274
|
+
- regex catastrophic backtracking과 과도한 CPU/memory 사용을 검사한다.
|
|
275
|
+
- allowlist가 hard-block entity를 우회하지 못하는지 테스트한다.
|
|
276
|
+
- prompt, MCP tool input/output, resource, artifact, log line별 fixture를 둔다.
|
|
277
|
+
- false positive와 false negative를 별도 측정한다.
|
|
278
|
+
- 필터링 전후 결과에 원문이 남지 않는 snapshot test를 수행한다.
|
|
279
|
+
- 외부 classifier를 사용할 경우 classifier 요청 payload에 개인정보가 전송되는지 별도 검사한다.
|
|
280
|
+
- region-deny, local-only, allowed-regions, transfer-mechanism missing 부정 테스트를 수행한다.
|
|
281
|
+
|
|
282
|
+
## 12. 미결정 사항
|
|
283
|
+
|
|
284
|
+
- 주민등록번호 등 고위험 식별자를 모든 환경에서 block할지, 폐쇄망/customer-managed-key 환경에서 tokenization을 허용할지 결정해야 한다.
|
|
285
|
+
- 이름/주소 탐지를 deterministic rule 위주로 할지 NER classifier를 포함할지 결정해야 한다.
|
|
286
|
+
- 개인정보 필터링 confidence threshold를 global default로 둘지 tenant별로 둘지 결정해야 한다.
|
|
287
|
+
- 필터링 결과를 LLM에게 placeholder로 설명할지, 완전히 삭제할지 결정해야 한다.
|
|
288
|
+
- GDPR/UK GDPR transfer mechanism을 제품이 hard enforcement할지, customer-provided evidence validation으로 둘지 결정해야 한다.
|
|
289
|
+
- HIPAA/PCI sector profile을 MVP에 포함할지 결정해야 한다.
|
|
290
|
+
- custom filter DSL을 자체 YAML 스키마로 유지할지, CEL/OPA/Rego 등 기존 표현식을 제한적으로 채택할지 결정해야 한다.
|
|
291
|
+
- 고객 제공 dictionary를 제품 관리 KMS로 암호화할지 customer-managed key만 허용할지 결정해야 한다.
|
|
292
|
+
|
|
293
|
+
## 13. 참고
|
|
294
|
+
|
|
295
|
+
- 개인정보의 안전성 확보조치 기준: https://law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000192069&chrClsCd=010201
|
|
296
|
+
- 개인정보보호위원회 개인정보보호지침: https://law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000240116
|
|
297
|
+
- KISA 암호이용 FAQ: https://seed.kisa.or.kr/kisa/bbs/faq.do
|
|
298
|
+
- European Commission GDPR overview: https://commission.europa.eu/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en
|
|
299
|
+
- European Commission SCC: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
|
|
300
|
+
- California CCPA: https://www.oag.ca.gov/privacy/ccpa
|
|
301
|
+
- HHS HIPAA Privacy Rule: https://www.hhs.gov/hipaa/for-professionals/privacy/index.html
|
|
302
|
+
- NIST Privacy Framework: https://www.nist.gov/privacy-framework
|
|
303
|
+
- Japan PPC APPI: https://www.ppc.go.jp/en/legal/
|
|
304
|
+
- Singapore PDPC: https://www.imda.gov.sg/About-IMDA/Data-Protection/personal-data-protection
|
|
305
|
+
- Canada PIPEDA: https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief
|
|
306
|
+
- Brazil LGPD: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/outros-documentos-e-publicacoes-institucionais/lgpd-en-lei-no-13-709-capa.pdf/view
|
|
307
|
+
- PCI DSS: https://www.pcisecuritystandards.org/standards/pci-dss/
|