Add Fusion ingress/egress policy setup guide
This commit is contained in:
46
fusion/POLICY_SETUP.md
Normal file
46
fusion/POLICY_SETUP.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# Fusion policy setup (steps 2, 3-route, 8)
|
||||
|
||||
This is the one part that isn't Terraform/CLI — it's configured in the Amplify
|
||||
AI Gateway (Fusion) itself. Below is the flow the gateway must implement. It is
|
||||
the orchestration + transformation layer only; detection and the vault are the
|
||||
separate components it calls.
|
||||
|
||||
## Endpoints to fill in
|
||||
- `PRESIDIO_URL` = `http://<presidio-task-ip>:5001/analyze`
|
||||
- `VAULT_TABLE` = `hncb-deid-demo-vault` (DynamoDB)
|
||||
- `AGENT_RUNTIME_ARN` = printed by `scripts/agentcore_setup.sh` (step 3)
|
||||
|
||||
## Ingress policy (advisor request → cloud)
|
||||
1. **Authenticate** the advisor and apply the RBAC / business-purpose check.
|
||||
2. **Detect**: POST the raw query to `PRESIDIO_URL`. You get back typed findings:
|
||||
`[{entity_type, start, end, score, text}]`. (Findings, not redaction.)
|
||||
3. **Mint + splice** (Fusion owns this):
|
||||
- for each finding, generate a fresh **random** token — different every request.
|
||||
Convention: `CUST_<random>` for a PERSON that resolves to a customer,
|
||||
`TW_<random>` for a `TW_ROC_ID`, etc.
|
||||
- write the reversible entry to the vault:
|
||||
`{ token, type, value, session_id, expires_at }`
|
||||
- replace each finding's span in the text with its token.
|
||||
4. **Route**: invoke `AGENT_RUNTIME_ARN` with `{ "prompt": "<de-identified text>" }`.
|
||||
5. **Trace**: log the **tokenized** payload only — never the pre-substitution text.
|
||||
|
||||
## Egress policy (cloud response → advisor)
|
||||
1. Receive the agent's de-identified result.
|
||||
2. **Restore**: for this `session_id`, look up the vault and re-attach the real
|
||||
identity (envelope-level here — the talking points are generic, so you prepend
|
||||
"王小明 —"; if any token appears inline, swap it back too).
|
||||
3. Return `{ "final": "<restored answer>", "deidentified_prompt": "<what the cloud saw>" }`
|
||||
so the UI can show the split view.
|
||||
|
||||
## Vault item shape (DynamoDB)
|
||||
```
|
||||
{ "token": "CUST_000123", "type": "CUSTOMER", "value": "cust-0001",
|
||||
"session_id": "<conv id>", "expires_at": <epoch+ttl> }
|
||||
```
|
||||
|
||||
## Demo-simplest alternative
|
||||
If wiring all of this into Fusion policy is too much for the first recording,
|
||||
implement steps 2-5 as a thin Fusion flow that calls a small "tokenizer" Lambda
|
||||
(detect → mint → vault write → splice) and a "restore" Lambda on egress. Same
|
||||
architecture on screen, less console clicking. The point of the demo is that the
|
||||
gateway owns the flow and the cloud only ever sees tokens.
|
||||
Reference in New Issue
Block a user