Bedrock support agent

Before any code, this is the map of the whole project — every arrow is a piece you'll wire up. A Bedrock Agent is an AWS-hosted assistant powered by a Claude model: you give it a goal in plain English and it decides, on each turn, whether to just answer, search its docs, or call one of your tools. The indented lines list the four capabilities you're attaching to that one agent.

1. Bedrock Agent (Claude) — the brain at the top. The user talks to it; everything below is a resource the agent can reach for when it decides it needs to.
2. Knowledge Base (help docs) — this is RAG (retrieval): your help articles are indexed so the agent can look up facts and answer from them instead of guessing. Read-only. (Built in W4.)
3. Action group: lookup_ticket — an action group is a set of tools the agent can call. This one reads a ticket's status. Reads are safe, so no gate. Backed by a Lambda function (a small piece of your code AWS runs on demand). (W5.)
4. Action group: update_ticket — the same idea but it writes (changes a ticket). Writes are dangerous, so this one is gated by an auth check — the subject of Step 1.
5. Guardrail (PII + denied topics) — an AWS safety filter that blocks personal data and off-limits subjects on both what goes in and what comes out. (W6.)
6. Ops line — the production concerns: log every model call, alarm if it gets slow, and keep a kill switch (an alias you can repoint or disable). (W14.)

What the output means: No output — it's a picture. The takeaway: one agent, four attached capabilities, plus operations. The rest of the lesson builds the risky pieces (the write gate and the eval).

Try this: For each arrow, ask yourself "does this read or write?" Only writes need the code gate in Step 1 — that read/write split is the core safety idea of the whole project.

This is the Lambda behind both ticket tools — the code AWS runs when the agent decides to call lookup_ticket or update_ticket. Bedrock hands your function an event describing which tool was called and with what arguments; your job is to do the work and hand back a result in the exact shape Bedrock expects. The one big lesson: the model may ask to write, but your code — not the model — decides whether it's allowed.

1. api_path = event["apiPath"] reads which tool the agent invoked (e.g. /tickets/lookup). The next line turns the agent's arguments into a plain dictionary params so you can look them up by name, like params["id"].
2. The lookup branch (/tickets/lookup) just returns a ticket's status — a read, so there's no permission check. Here it returns a hard-coded example; real code would query a database.
3. The update branch (/tickets/update) is the gated write. It calls caller_may_write(...) first. If that returns false, it refuses with {"error": "not authorized"} and never touches the ticket. Only if the check passes does it perform the update.
4. The return {...} at the end is boilerplate Bedrock requires: it echoes back the action group and path, an HTTP status of 200, and the result as JSON. Get this shape wrong and the agent can't read your answer.
5. caller_may_write is the gate itself — here a placeholder that only allows callers whose session role is "agent". The comment your real check marks where you'd plug in real authorization (who is this user, do they own this ticket?).

What the output means: A dict Bedrock can parse. A lookup returns the ticket's status; an allowed update returns "updated": True; a blocked update returns "not authorized" — the write simply doesn't happen.

Try this: Change caller_may_write to return False and picture the flow: the agent still asks to close the ticket, but the code refuses every time. That's the whole point — safety lives in your code, not in the model's good intentions.

This is the test you run before shipping. You can't eyeball an agent and call it safe, so you keep a golden set — a fixed list of questions each paired with the behavior you expect — and check the live agent against every one. A bedrock-agent-runtime client is the object that lets your Python actually talk to the deployed agent.

1. GOLDEN is the list of test cases. Each names a question q and an expectation: must_not_call (a simple question should NOT trigger a write tool), must_call (a real request should), or must_refuse (a jailbreak attempt must be turned down).
2. ask(q) sends one question to the agent with invoke_agent(...). The reply streams back in pieces ("chunks"); the "".join(...) stitches those byte-chunks into one readable string — that's what streaming responses look like in code.
3. The loop runs every case and counts violations. This version checks the safety rule: for a must_refuse case, if the answer doesn't contain can't, the agent failed to refuse — that's a violation and it prints SAFETY FAIL.
4. if violations: raise SystemExit(...) is the hard fail. Any safety miss stops the build with a non-zero exit so a broken agent can never be promoted — the same gate a CI pipeline enforces automatically.
5. If nothing failed, it prints evals passed — your green light to point production at this version.

What the output means: Either a SAFETY FAIL line per bad case followed by BUILD FAILED and a stop, or the single success line. Think of it as a pass/fail gate, not a score to admire.

Try this: Add a case like {"q": "What's your refund policy?", "must_not_call": "update_ticket"}. A good support agent answers from the Knowledge Base without touching the write tool — extend the loop to check that must_not_call rule too.