Skip to content
Agile Defense

Curriculum / AI Engineer — AIP Builder

ADVANCEDUnit 7unit-07

Wrap it in governance: permissions, Markings, staged edits, audit

not started~300 min
Deliver the recommendation's Ontology edit via a governed Action (submission criteria / staged-for-review, not auto-applied), minimize tool scopes, and map the workflow to responsible-AI themes.

Introduction

Scenario: The Disruption Copilot can now recommend a response to a supply-chain disruption, but a wrong recommendation that silently rewrites the Ontology would be unacceptable to the operations team that depends on it. Your job is to wrap the capability in governance so every LLM-driven edit reaches a DisruptionEvent only through a human-reviewed Action, with tool and data access held to least privilege.

Until now you built a capability that produces a recommendation; this unit makes that capability safe to operate. AIP governance gives you granular permissions and roles, data Markings, audit logs of every system interaction and model decision, structured approval workflows, and human-in-the-loop checkpoints. The core move here is to stop the recommendation from auto-writing the Ontology and instead route the edit through a governed Action whose changes are staged for review under submission criteria, so a person — not the model — owns the final commit. You will confirm the governing Action exists, then prove that a reviewer-approved edit actually landed on a DisruptionEvent.

The reason this is the hard, important part is that an LLM recommendation is probabilistic, but an Ontology edit is consequential and durable. By delivering the edit through an Action with submission criteria rather than an auto-applied Apply action, you convert the model's output into a proposal that a reviewer must accept, reject, or amend. The Action becomes the single auditable choke point: it carries parameters, runs against the Ontology under the reviewer's permissions, and leaves a trace. Alongside the Action you tighten the workflow with least-privilege Markings and permissions so the model, the published functions, and the chatbot can only reach the objects and tools they genuinely need — the same least-privilege principle AIP Chatbot Studio already enforces so the LLM accesses only what is necessary.

An honest constraint shapes how this unit is checked. Most governance configuration is not exposed by any decision-support READ API: you cannot enumerate the submission-criteria or staged-review settings of an Action, you cannot read back which Markings or permissions are applied, and registered (BYOM) models do not support Markings at all — a caveat that matters acutely in a defense context. So the validation does not inspect the governance config; it observes the effect. The graders confirm the governing Action type exists with its parameters, and confirm a DisruptionEvent now carries an owner and a governed status, which is only possible if a reviewed edit took effect. The Markings/permissions scoping and the responsible-AI mapping are self-attested and reviewed by hand, because no API can confirm them for you.

Capability focus: Governed Actions (staged review/submission criteria); least-privilege Markings/permissions; responsible-AI governance themes. · Artifact: A governed configuration where the edit flows through a reviewed Action, with tool scopes minimized and the workflow documented.

Key concepts

  • AIP governance: AIP provides granular permissions and roles, data Markings, audit logs of all system interactions and model evaluation/deployment decisions, structured approval workflows via checks, human-in-the-loop checkpoints, and georestrictions. These are the concrete controls you assemble around an LLM-driven workflow rather than abstract policy.
  • Function-backed Actions: An Action is the governed write path into the Ontology — it carries typed parameters and applies the edit under the acting user's permissions. Routing the recommendation's edit through an Action (here, escalateDisruption) means changes are governable, auditable, and attributable, instead of ad-hoc writes performed directly by the model.
  • Staged-for-review / submission criteria: Rather than auto-applying an edit, you configure the Action so the proposed change is staged and must satisfy submission criteria — a human-in-the-loop checkpoint where a reviewer approves, rejects, or amends before the edit commits. The staged-review configuration itself is governance metadata and is not enumerable through a decision-support READ API; only its effect on object state is observable.
  • Least-privilege Markings and permissions: Markings and permission scoping restrict which objects, properties, and tools the LLM, the published functions, and the AIP Chatbot can reach, mirroring the least-privilege model AIP Chatbot Studio enforces so the LLM only accesses what is necessary. Defense caveat: registered (BYOM) models do NOT support Markings, so a BYOM-backed function cannot rely on Markings for data isolation and must be scoped by other permission controls.
  • Responsible-AI themes: Palantir frames responsible AI as concrete capabilities across themes including Explainable, Reliable, Traceable, Accountable, and Human-centered. A governed disruption workflow maps directly: audit trails make it Traceable, a named reviewer and owner make it Accountable, and the staged-review checkpoint makes it Human-centered.
  • Effect-over-config validation: Because most governance settings are not API-readable, this unit is graded on observable outcomes — the existence of the governing Action type and the resulting object state of a reviewed DisruptionEvent (an assigned owner and a governed status) — rather than by inspecting submission criteria, Markings, or permission grants, which no documented READ API surfaces.

Companion video

Tool Use in AIP Agents: Actions · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Governing Action type exists with parameters

    Confirm that the recommendation's Ontology edit flows through a governed Action rather than an ad-hoc write by ensuring the governing Action type, escalateDisruption, exists with its parameters. List Action Types / Get Action Type confirms the apiName and the parameters the Action accepts; the recommendation (from AIP Logic or the published function) should target this Action instead of writing to DisruptionEvent directly. Define the parameters the reviewer needs to act on — at minimum the disruption being escalated, an owner to assign, and the governed status to set — so the Action is the single, typed, auditable write path into the Ontology.

    not startedinstance check

    Confirms the governing Action (escalateDisruption) exists so edits flow through a governed Action, not ad-hoc writes.

  2. 2

    Human-in-the-loop effect is observable as object state

    Prove the human-in-the-loop path actually worked by observing object state, since the staged-review and submission-criteria configuration of the Action is governance metadata that no decision-support READ API enumerates — the effect is the only thing you can confirm. Configure escalateDisruption to stage its edit for review under submission criteria rather than auto-applying it, then have a reviewer approve the proposed edit on a seeded DisruptionEvent. The grader uses List Objects / Get Object to confirm that at least one DisruptionEvent now carries a non-empty owner and a governed status of escalated or in-review; that combination is only reachable if a reviewed Action committed the edit, which is the evidence that the governed path took effect. Do not auto-apply the edit to make the check pass — the point is that a person, not the model, owned the commit.

    not startedinstance check

    Confirms a reviewer-approved edit took effect: a DisruptionEvent now has an owner and a governed status.

  3. 3

    Markings / permissions scope the workflow

    Apply least-privilege Markings and permissions so the LLM, the published functions, and the Disruption Copilot chatbot can reach only the objects, properties, and tools they genuinely need, mirroring the least-privilege model AIP Chatbot Studio already enforces. Scope the Object query tool and any Function tool to the minimal disruption object types and properties, and restrict the Action's caller and reviewer roles to the intended groups. This step is self-attested: Marking and permission configuration is governance metadata that no documented decision-support READ API exposes, so a reviewer verifies it by hand. Record the defense caveat explicitly — registered (BYOM) models do NOT support Markings, so any BYOM-backed function must be isolated through other permission controls rather than relying on Markings for data separation.

    not startedself-attested

    Self-attested: Markings/permissions restrict the objects and tools the LLM and chatbot can reach.

  4. 4

    Workflow mapped to responsible-AI themes

    Document how the build satisfies the responsible-AI themes so the governance is legible to an operator and an auditor, not just implied by the configuration. Map the workflow concretely: audit logs of every interaction and the auditable recommendation-to-edit trace make it Traceable; a named reviewer and the assigned DisruptionEvent owner make it Accountable; and the staged-for-review submission-criteria checkpoint, where a person approves before any edit commits, makes it Human-centered. This step is self-attested because a written mapping is reviewable by an instructor but not API-confirmable — there is no endpoint that reads back your governance narrative. Tie each claim to a control you actually configured (the escalateDisruption Action, the staged review, the scoped tools and Markings) so the mapping is defensible rather than aspirational.

    not startedself-attested

    Self-attested: the build is documented against Traceable / Accountable / Human-centered themes.