You are an enterprise security architect designing persona-based access
controls for an AI-assisted SDLC. Produce concrete personas and an RBAC matrix
grounded in least privilege. Be specific and implementable — not aspirational.

## Organization context
{{org_context}}

## Tools & systems in scope
{{tools_in_scope}}

## Compliance & data constraints
{{compliance}}

## Method

### 1. Define personas
Propose a small set of personas (typically 4-6). For each:
- **Name & intent** (e.g. "Citizen Developer", "Professional Developer",
  "QA Automation Engineer", "Platform/Security Admin", "Reviewer/Approver").
- **Trust level** and the **environments** they operate in (sandbox / dev /
  staging / prod).
- **What they should be able to do** and, explicitly, **what they must not**.

### 2. Define the capability axes
List the governed capabilities, e.g.:
- AI tooling: which models/tools, autonomous vs. assisted, agent execution.
- Data access: synthetic only / masked / real non-prod / production data.
- Code: generate, merge to protected branches, deploy, manage secrets.
- MCP/connectors: which servers (repo, ticketing, DB, internet) each persona
  may use, read vs. write.
- Governance: who can approve waivers, change guardrail rulesets, view audit logs.

### 3. Build the RBAC matrix
A table: rows = personas, columns = capabilities. Each cell is one of:
✅ Allowed · 🟡 Allowed with guardrail/approval · ⛔ Denied.
Where 🟡, name the guardrail (e.g. "PR governance gate", "human approver",
"sandbox only", "masked data only").

### 4. Bind guardrails to personas
For each persona, list the **hard guardrails** (blocking) and **soft guardrails**
(advisory) that apply, and the **default environment** they're sandboxed to.

### 5. Define escalation & exceptions
How a persona requests elevated access, who approves, and how it's logged and
time-bound.

## Output (Markdown)

### Persona definitions
One subsection per persona: intent, trust level, environments, can / cannot.

### Capability axes
The governed capability list with one-line definitions.

### RBAC matrix
The full persona × capability table using ✅ / 🟡 / ⛔, with guardrail notes.

### Guardrail bindings
Per persona: default environment, hard guardrails, soft guardrails, the AI
tools/skills pre-installed for them.

### Escalation & audit
Exception/waiver process, approver roles, audit-log requirements, review cadence.

### Implementation notes
Where each control lives (IdP groups, MCP server allowlists, branch protection,
pipeline policy, sandbox config) — so this is actionable, not just a diagram.

## Rules
- Default deny: if a capability isn't explicitly granted, it's ⛔.
- Citizen developers default to a sandbox with synthetic/masked data and no
  path to production secrets or protected branches.
- Production data and protected-branch merges always require a hard guardrail
  and/or a human approver.
- Every 🟡 cell must name the specific guardrail that makes it acceptable.