| name | insurance-authz |
| description | SecureHome Insurance dataset authorization vocabulary - the exact subject/action/resource values defined by this project's KBAC policies. Load together with the authzen skill whenever composing an AuthZEN request in the SecureHome demo, so types, actions, and ids are never guessed. |
| tags | ["authzen","authorization","insurance","dataset"] |
| examples | ["Can I trigger workflow wf1?","Which workflows can I trigger?","Am I allowed to run the drive workflow?","Which documents can I view?","Can Sarah (adult-002) see the insurance coverage details?"] |
SecureHome Insurance authorization vocabulary (dataset-specific)
This skill belongs to the SecureHome Insurance demo dataset, not to
AuthZEN in general. It lists the vocabulary of this project's active KBAC
policies - the only (subject, action, resource) triples that can ever
evaluate to true here. Use these exact, case-sensitive values in AuthZEN
requests:
| subject_type | action_name | resource_type | known resource ids |
|---|
Person | CAN_TRIGGER | Workflow | wf1, wf2, wf3, wf-drive, wf-drive-analyst, wf-drive-console, wf3-console, wf-crm |
Person | CAN_VIEW | Document | claims_handling_policy, underwriting_guidelines, home_policy_terms |
- Every subject is a
Person - there is no User subject type in this
dataset. Staff carry the Employee label and reach workflows and
documents through their department's edges; customers hold direct
CAN_TRIGGER edges.
subject_id is the logged-in person's external_id (e.g. millicent,
rebecca, leslie, james); resolve it via the get-self knowledge
query if unknown.- Staff (via
Department -CAN_VIEW->) can view all three documents and
trigger every workflow.
wf-crm (Salesforce case filing) is staff-only: the departments hold the
CAN_TRIGGER edge, customers do not - a customer asking to open a CRM case
is denied by design.- Customer
james (= James Mitchell) can trigger the chat workflows
(wf1/wf2/wf3) but NOT the Drive ones or wf-crm, and can view only
home_policy_terms - the customer-facing document the company publishes
(published-document-viewable policy). Denials on the rest are by design.
- Other household members (
adult-002, teen-001, teen-002) are data
subjects reached through knowledge queries.
- Word mapping: workflow / agent flow ->
Workflow + CAN_TRIGGER;
document / policy paper / terms -> Document + CAN_VIEW.
- Any other type or action name (e.g.
User, user, view, execute)
evaluates to false regardless of the person's real permissions.
Not an AuthZEN question: policy DATA visibility
Questions about what a person can see IN the insurance data - coverage
details, premium, deductible, policy financials, household coverage - are
NOT authorization checks. No KBAC policy covers HomeInsurance or any
other data type, so an AuthZEN evaluation would return false regardless
of the person's real access. Coverage visibility is graduated (the primary
policyholder sees financials, other household members see less), and only
the get-home-insurance-access knowledge query can express that.
- "Can Sarah (adult-002) see the insurance coverage details?" -> run
ciq_execute with {"id":"get-home-insurance-access","input_params":{"caller_id":"adult-002"}} and
describe what the result shows her. Never answer "not authorized" to a
coverage-data question.
- AuthZEN answers ONLY the two triples in the table above: may a person
TRIGGER a workflow, may a person VIEW a document.
- "Why can't X see ..." presupposes a denial - never accept that premise
without running the tool. Run the query (or, for documents, the AuthZEN
check) first; if it shows access, correct the question: "She can - ..."
Never invent an authorization reason that no tool call produced.
Maintenance note: keep this table in sync with the insurance dataset's KBAC
policies (instant-stack data/insurance/manifest.json, kbac section).
Remove this skill if the dataset changes or once the platform exposes policy
vocabulary through the MCP server itself.
