Summary: An IT team governing employee AI tools needs to know who owns each agent, which actions it may take, and who can change that authority. A tool inventory alone cannot show whether a denied operation stopped. APort's decision-versus-enforcement notes describe the evidence needed to distinguish a policy result, an operator's rollout mode and the actual runtime outcome.
A Team Pilot should produce that evidence for a bounded workflow. Start with one group of developers and the tools they already use. The objective is a reviewable operating practice, not an unsupported claim that every employee action is governed.
Write the pilot contract before installing hooks
Name the workflow and its owner. For example, a team may allow repository reads and ordinary development commands while treating secret reads, external exports and protected CI changes as review-sensitive. That is a proposed pilot scope; the actual policies must be checked against the selected adapters.
Record who may edit passports, who approves exceptions, who can switch enforcement modes and who responds when verification is unavailable. Keep these permissions outside the agent's own tool-call parameters.
The AI passport product page describes the identity and scope model. The runtime quickstart identifies available setup paths. Use both when deciding what the pilot can demonstrate.
Put rollout evidence in front of the owners
| Owner | Decision to make | Evidence for the review |
|---|---|---|
| Engineering lead | Which legitimate tasks must continue? | Allowed fixtures exercised through the team's tools |
| Security owner | Which actions must stop? | Denied fixtures with observed absence of side effects |
| IT administrator | Who controls installation and configuration? | Active settings and a tested update procedure |
| Audit owner | Which records are retained and where? | Signed hosted decisions, runtime reports and missing-data labels |
These are recommended responsibilities, not a claim that a product assigns the roles automatically. A useful pilot gives each owner enough evidence to accept or reject the proposed deployment.
Move from report-only to enforcement deliberately
Report-only can reveal policies that interrupt normal work. Preserve its denied decisions as denials even when the tool continues, and label that runtime behavior. Decide which findings should become blocking only after the team has exercised legitimate and prohibited operations.
For Claude Code and Cursor, validate the active runtime separately. A shared policy model does not remove differences in hooks, configuration or tool coverage. For GitHub Guard, a required check and branch rules are part of enforcement; a successful report-only job is insufficient.
An outage exception should have an owner and a defined scope. It must not silently convert a real policy denial into an availability fallback.
Choose the audit boundary with the deployment
Local/offline decisions remain local unless telemetry is enabled. Hosted verification supports centralized decision evidence, but the default GitHub OIDC path uses an APort-owned repository passport. Teams needing decisions in their own organization should review the managed hosted audit configuration.
Retain the fields needed to explain a decision, rather than raw prompts, secrets or full customer records. Where the runtime does not report what executed, preserve that absence as unknown.
Set a rollout decision the team can reverse
A small pilot can use three review stages. In inventory review, record the actual installed tools, credential owners and reachable services. In observation, exercise normal work with disposable or low-impact resources and inspect what the policies would deny. In enforcement review, prove that the selected denials stop at the intended boundary before expanding authority.
Keep an exception record with the workflow, owner, reason, permitted scope and review date. An exception should change trusted configuration through the team's process; an agent claiming urgency in a prompt is not that process. If an outage requires fallback, record who accepted continued execution and what operations remain permitted.
For evidence quality, track the proportion of defined pilot operations with a tested enforcement point, rather than the raw volume of decisions. Count unknown runtime outcomes separately. A dashboard with many rows can still miss the one unconnected export tool that matters.
The deliverable is a go/no-go decision by the named owners: the engineering lead accepts legitimate-task behavior, security accepts the prohibited-action results, and IT accepts control of installation and configuration. If one runtime remains untested, keep it outside the accepted scope and document the remaining work.
Accept the pilot on observed behavior
Before expanding, require the named workflows to pass their allowed fixtures, stop their denied fixtures in enforce mode, and show the chosen behavior during a verifier outage. Review configuration ownership and the evidence retention path with the people who will operate them.
Plan your Team Pilot with that workflow, its tool list and its acceptance checks.