AETERION

    Write a policy

    This guide turns an existing control — an approval threshold, a residency requirement, a field restriction — into a BRAIAN policy enforced at runtime. You will express the rule, scope it to the tools it protects, test it against recorded runs, review its predicted effect and activate it in one environment at a time.

    View as markdown

    Start from a control that already exists

    Most organisations already have the rule written somewhere: a signature matrix, a data protection register, an internal control framework. Translate that rule rather than inventing a new one, so the enforced behaviour matches the approved behaviour.

    Express and scope the rule

    A policy names the tools it protects. Anything outside that scope is unaffected, which keeps policies small and reviewable.

    hr.field-access.yaml
    name: hr.field-access
    applies_to:
      tools: [hris.employee.read]
    rules:
      - mask_fields: [salary, iban, national_id]
        when: agent != hr-payroll-agent
      - default: allow

    Test against recorded runs

    Testing replays the policy over historical runs and reports which calls would have been allowed, escalated or denied. Review the denials before activation: a policy that blocks routine work will be bypassed by people rather than followed.

    bash
    braian policy test hr.field-access --against last-90d --report ./policy-impact.json

    Activate one environment at a time

    bash
    braian policy activate hr.field-access --env staging
    braian policy activate hr.field-access --env production