Permissions, Privacy, and Auditability

Connected AI has a quiet failure mode: nothing breaks, but access spreads. A connector added for one team gets reused by another; a workflow built for one purpose starts feeding a second; nobody can quite say who approved what. The antidote is the principle from the MCP lesson, now applied as governance: AI workflows inherit existing responsibilities — they never quietly create broader access, weaker retention, or unowned actions.

Least privilege, four layers deep

Grant the minimum user group, system, records, fields, actions, and duration the workflow requires — and check it at every layer, because each is a separate decision someone owns:

1. Who may use the Claude surface at all
2. Which connectors that user may invoke
3. What the connector may access in the source system
4. Which generated action still requires human approval

Northstar's pipeline-review workflow reads cleanly across the layers: sales managers (1) may use the CRM connector (2), which reads selected opportunity fields for their own region (3), and any record update requires the manager's approval (4). Keep read and write permissions separate, and manage access through identity-provider groups rather than individual grants — groups follow role changes; individual grants outlive them.

Privacy is purpose, not just protection

Three questions per workflow, in order: Why is personal data needed here at all — documented, not assumed? How little of it can the task run on? How long does it persist in conversations, logs, and outputs, and does that match existing retention and deletion duties?

The trap to name in review: a connector can make data technically available that was never approved for this purpose. The support workflow can see purchase history; that does not make purchase history fair game for a marketing workflow that borrowed the connector. Repurposing data because a pipe already exists is how privacy programs fail while every individual control still works.

An audit trail that answers questions

Design the trail backward from the questions an auditor, a security incident, or an annoyed executive will actually ask:

• Who initiated the workflow?
• Which sources and tools were used?
• What did the system produce or change?
• Which person approved the consequential action?
• Which version of the workflow was active?
• What happened when it failed?

If your logs answer all six, investigations take minutes; each gap turns the same investigation into guesswork. And note the recursion: logs that capture prompts and outputs may themselves contain sensitive data — scope their access and retention like any other sensitive store, or the audit trail becomes the leak.

Someone operates this

Controls decay without owners. Name one for each: periodic access review, connector changes, incident response, and offboarding. Then recheck access on every trigger — role changes, source-system changes, workflow-scope changes. The workflow that was least-privilege at launch is not automatically least-privilege in six months; only the review makes it so.

Practice

Create the permissions map for your capstone: user groups, systems, data scope, allowed actions, approval gates, what is logged, retention, and the named owner of each review. One page. If a box has no owner, you have found this exercise's finding.

Definition of done

For your workflow you can answer, with evidence: who had access, why that access was needed, what occurred, and who remains accountable — including on the day something goes wrong.