Inspect the security mechanisms
Review local verification, credential boundaries, and control-specific failure behavior.
Open this resource →Data inventory
Review the information behind each connection.
Identify permitted runtime metadata, deliberately shared contributions, enrollment details, and separate external service flows.
Data review starts with specific records and purposes. Betterloop bounds runtime reports, while accounts, configuration repositories, and service authorizations have separate data flows.
01 / Data inventory
Map the records your team will create.
Harbor is a fictional company preparing an evaluation for its Search team. Its data owner starts with a list of records rather than a broad telemetry claim.
Connection records describe the device setup and release state. Session records describe supported lifecycle events. Policy records carry bounded context for a supported decision.
A contribution is different again. It contains a lesson that a developer deliberately submits after inspecting the bounded public content.
Accounts identify people and installations. GitHub holds reviewed configuration and its history. Native model providers and approved MCP services handle their own interactions.
A runtime exclusion applies to runtime reports. It does not describe information sent directly to a model provider by its native client.
Review these flows separately before enrolling Search devices. Use the inventory below to identify questions that the selected deployment agreement must settle.
02 / Data inventory
Inspect fields instead of relying on a slogan.
Bounded reporting means a defined set of fields rather than unrestricted work content. The permitted fields depend on the report type.
A policy event can identify the tool, program, rule binding, and bounded reason. It excludes a complete shell command and its arguments.
A model-related event can include its selector without the prompt or generated response. Session identifiers are opaque and scoped to the installation.
Native session identifiers and transcripts do not form part of session reports. Raw prompts, source, paths, command arguments, and credentials are excluded.
Trusted Claude hooks can identify skills, MCP servers or tools, and subagent types. They do not include resource inputs or returned content.
Diagnostics can count known unmanaged skill sources without uploading their paths or contents. Those counts do not prove the sources are inaccessible.
Internal names still carry meaning. A repository owner or service identifier can disclose business structure even when no application source accompanies it.
| Record | Permitted fields or content | Boundary to review |
|---|---|---|
| Connection readiness | Device identity, agent identity, release and reported setup state | Reports originate from the client rather than machine attestation |
| Session lifecycle | Opaque installation-scoped identifier and supported events | Native identifiers and session transcripts are absent |
| Policy outcome | Tool ID, program or model selector, rule binding and bounded reason | Complete commands, arguments, paths and output are absent |
| Unapproved repository event | Sanitized Git host, owner and repository, or opaque alias | The organization reporting requirement is independent of optional telemetry |
| Claude resource activity | Skill IDs, MCP server or tool names and subagent types | Resource inputs and contents are absent |
| Shared learning | Explicit bounded contribution with permitted outcome records | Terminal inspection and confirmation precede submission |
03 / Data inventory
Explain unknown-repository reporting to developers.
A repository without an approved match remains unapproved. An unresolved or missing remote does not silently create an approved assignment.
The default for a new organization baseline reports activity without supplying company rules or knowledge. The administrator may instead choose team defaults with reporting.
Both choices emit the required event for unknown repositories. Disabling optional telemetry does not suppress that reviewed organization requirement.
The record includes device and agent identity, timestamp, signed release, and sanitized Git host, owner, and repository. Unresolved identities receive an opaque alias.
It excludes repository paths, remote credentials, source, prompts, and command arguments. Deduplication uses the repository session and approval identity.
Offline events enter a bounded queue. Idempotent retry preserves event identity instead of creating a separate event for each delivery attempt.
Neither choice automatically assigns the repository. Neither allows company policy to block unapproved work. Team configuration cannot replace the organization's selected behavior.
For Search, the communication should distinguish required repository reporting from optional telemetry. Developers need that distinction before they connect their devices.
04 / Data inventory
Keep local improvement drafts separate from shared lessons.
Optimization drafts remain local to their repository, agent, and enrollment context. Candidate discovery does not place their contents in Git or an upload queue.
The developer may retain or dismiss a draft. Choosing to share displays the exact bounded public submission and requires confirmation in the terminal.
For a script-related submission, public fields include the summary, rationale, applicability, representation, task count, and content or evidence digests.
The learning contribution excludes script files, private instructions, paths, and verification commands. Distribution of scripts later uses reviewed repository references.
A digest identifies exact content without transmitting all its text. That property does not make a sensitive public summary acceptable.
Reviewers must still remove private detail and assess applicability. They review the bounded contribution rather than receiving a transcript of the original session.
A Search lesson could explain a recurring verification condition without mentioning a customer query or copying application source. Specificity should describe the reusable situation.
05 / Data inventory
Review authorization and third-party records separately.
The applicable knowledge index can be discovered without fetching every referenced document. Service authorization still determines whether a developer can retrieve a document.
Accounts use identity information. Team invite enrollment collects a developer name and work email to identify the installation.
Configuration repositories contain reviewed rules and resource history. Repository readers and review participants may have access to information beyond runtime report fields.
Native clients retain their model-provider relationships. Their prompts and generated work require review under the applicable provider arrangement.
Approved MCP services have their own accounts, requested scopes, and data handling. A connection definition does not settle those questions on its own.
The pilot inquiry uses Tally as a separate service. Provide only the information needed to discuss an evaluation rather than credentials or private source.
Use the intended authorization flow for secrets. Avoid credential values in configuration, lesson summaries, parameter defaults, or inquiry forms.
| Separate flow | Reason it exists | Question for the owner |
|---|---|---|
| Accounts and enrollment | Identify members and device connections | Which identity fields, access roles and deletion procedures apply? |
| GitHub configuration | Maintain reviewed rules and versioned resources | Who can read files and review history? |
| Native provider connection | Run the chosen coding client | Which provider agreement covers the submitted work? |
| MCP service authorization | Use an approved external system | Which account scopes and service terms apply? |
| Tally inquiry | Discuss pilot requirements | Which evaluation details are appropriate to submit? |
06 / Data inventory
Turn the inventory into a deployment decision.
List the intended agents and permitted report fields. Include the unknown-repository setting and the process for sharing a local lesson.
Separate required reporting from optional telemetry in that record. A statement about one setting cannot describe the other.
Ask for hosting, retention, deletion, subprocessors, and contact information for the actual deployment. Agree the requirements instead of assuming an unpublished default.
Identify who can access Connections, Sessions, and contributions. Define a contact and response procedure for an incorrect or sensitive submission.
Review later additions to the inventory. Approval of existing fields does not automatically cover a new identifier or external connection.
Can optional telemetry settings disable every report?
No. Required reporting for unknown repositories follows the reviewed organization setting independently of optional telemetry.
Are native client credentials imported?
No. Claude Code and Codex keep their native credential files. Supported MCP OAuth connections use a distinct authorization flow.
Where should we find binding retention commitments?
Settle them in documentation and agreements for the selected deployment. This inventory does not replace that notice or invent a retention period.