Policy Studio

ArmorEdu does not have a dedicated studio UI. You author and edit an ArmorEdu policy the same way you author any ArmorIQ policy: in the platform's Policy Studio, or by editing the bundle YAML directly and importing it. The domain control blocks (ferpaAccessControl, studentRecordControl, gradeReleaseControl, researchDataControl, grantControl, privilegedAccessControl) are ordinary fields on that document. See Concepts for what each one means.

Start from a bundle

The fastest path is one of the three bundle templates. Each is a complete armor.io/v1 Policy document with targetType: agent, an allowedTools list, toolEnforcement overrides, and the control blocks for its domain. Copy the bundle that matches your agent's role (course management, research, or IT operations) and edit it in the Single Policy editor or as raw YAML.

Set the target

Each bundle ships with a placeholder metadata.targetId: a UUID for the demo agent it was written against. Before the policy can do anything in your organization, replace it with the ID of your registered agent:

metadata:
  name: armoredu-course-controls
  targetType: agent
  targetId: "<your-agent-id>"      # was the demo course-management agent

A policy with targetType: agent only evaluates tool calls from the agent named in targetId. If the ID doesn't match a registered agent, or matches the wrong one, none of the bundle's rules will apply to the traffic you're watching. See Troubleshooting if enforcement seems to be missing entirely.

Review allowed tools and overrides

allowedTools is the full list of tool names the agent may call at all; anything not on the list falls through to the policy's fail-closed default. toolEnforcement then overrides the action for specific tools in that list. This is where a bundle's block and hold behavior actually lives:

spec:
  defaultEnforcementAction: allow_log
  memberRules:
    "*":
      allowedTools:
        - get_course_info
        - export_student_records
        - publish_final_grades
      toolEnforcement:
        export_student_records: block
        publish_final_grades: hold

Resolution order is specific to general: a toolEnforcement entry for a tool wins, then the rule's own action, then defaultEnforcementAction, and finally a fail-closed block if nothing matches. See Concepts for the full table.

Before tightening a tool to hold or block, confirm it actually appears in your agent's real tool calls: a name that doesn't match what the agent sends (a typo, a different casing, a renamed tool) silently falls through to the default action instead of the override you intended.

Edit the domain control blocks

The control blocks are declarative fields alongside allowedTools and toolEnforcement, not separate policies. Edit them directly in the YAML (Policy Studio's generic editor doesn't currently render ArmorEdu-specific form fields for them, unlike the specialized studios ArmorPay and ArmorHealth have for their domains):

      ferpaAccessControl:
        allowedDataCategories: [directory, enrollment, grades]
        requireLegitimateInterest: true
        redactStudentId: true
      gradeReleaseControl:
        requireApproval: true
        allowedGradeStatuses: [final]

Change the values to match your institution: for example, add or remove data categories, tighten holdAboveAmount in grantControl, or add roles to privilegedAccessControl.allowedRoles. These fields don't independently enforce anything; they document intent alongside the allowedTools / toolEnforcement fields that the engine actually evaluates per tool call.

Draft, shadow, and active

A policy's status moves through the same lifecycle as any ArmorIQ policy:

Import a bundle as active directly, or set it to draft and use shadow mode to compare its decisions against your current policy on the same agent before promoting it. A policy can only enter shadow if it isn't already active, and only a shadow policy can be promoted to active. See platform policies for the general engine and Policy Studio for where these actions live in the UI.

Next steps