Examine permitted report fields
Bring a concrete data inventory to the deployment review.
Open this resource →Security review
Trace who approved it and what reached the client.
Inspect configuration authority, artifact verification, local execution limits, and credential handling as separate parts of the deployment.
A security review needs more than a product status. Betterloop separates approved configuration, verified artifacts, native controls, and the reports used to investigate them.
01 / Security review
Begin with distinct security questions.
Harbor is an imaginary company evaluating Betterloop for its Search team. Its reviewers need to understand several boundaries before connecting search-api developers.
Who may revise the team setup? How are released files protected from substitution? Which operations can the selected client actually check?
Where do credentials remain? Which fields reach Betterloop? What happens when a network request fails or a signed artifact expires?
These questions call for different evidence. Git review concerns authority. Signatures concern artifact integrity. Runtime tests concern the behavior of a particular supported boundary.
The native client and external service retain their own permissions. Signed instructions do not provide additional access to either system.
A client can therefore have a valid artifact and an uncovered execution path at the same time. Record both facts instead of combining them into one assurance.
For each evaluation, identify the operating system, client version, release, required action, and external connections. Those conditions define what the result supports.
02 / Security review
Connect a reviewed commit to a verified artifact.
The reviewed Git revision selects exact resource versions. Digests identify the selected file contents, and published resource directories remain immutable.
Compilation validates resource types and applies inheritance. An isolated signer then creates compatible runtime artifacts after the approval requirements are met.
Before activation, the client checks signature, digest, scope, expiry, runtime compatibility, and known revocation. Material that fails validation is not activated.
Clients use signed content instead of replacing configuration directly from mutable Git files. This keeps review and local artifact selection connected.
Approval and signing still answer different questions. A reviewer can approve a change whose release later fails to compile or sign.
Likewise, a verified signature does not establish that the host invoked a native hook. Activation needs evidence from a fresh working session.
For Harbor, trace the approved Search revision to the reported device release. Then test the specific operation that the security requirement concerns.
Retain the tested artifact and client versions in the review record. Later changes should not inherit an assurance that covered different software.
03 / Security review
Inspect executable resources as executable work.
A skill provides workflow guidance. A role provides reviewed instructions. A hook can execute at a supported client lifecycle event.
Registry hooks use bounded Node execution with limited environment inheritance. Their lifecycle input excludes work content, and structured output and execution time are bounded.
A hook may restrict a covered operation. Native approval remains authoritative, so the hook cannot grant a permission the client has withheld.
Discovering a resource does not execute its helper files. Review the installation and event binding before expecting a script to run.
Some completion or continuity behavior remains advisory where a host has no covered boundary. Installed scripts and actual invocation are different observations.
Shell authorization has another limit. An approved program can execute code or start other programs; literal command checks do not provide operating-system containment.
Review owners should inspect file contents, parameters, ownership, applicable events, and failure behavior. A reassuring resource name cannot replace that examination.
If a required path is outside the integration, record the remaining risk. Stronger wording in the configuration does not close it.
04 / Security review
Authorize services without putting secrets in configuration.
Claude Code and Codex continue to use their native subscription credentials. Betterloop does not copy those native credential files into its configuration.
MCP definitions identify an approved endpoint and authorization requirements. Developers authorize their own service accounts; that login does not enlarge shared tool permissions.
For supported macOS connections, the shared proxy places OAuth tokens in Keychain. A Keychain error requires repair rather than storage in plaintext.
Authorization reuse depends on the approved connection. A changed endpoint, issuer, resource, or scope invalidates reuse of the previous authorization.
Use credential references in configuration and knowledge references. Credential values do not belong in Git, contribution text, or parameter defaults.
For Search, approving a documentation service makes its reviewed definition available. It does not grant a developer permission to read the service's documents.
The same separation applies to application repositories. Betterloop enrollment and project assignment do not substitute for GitHub access approval.
Test discovery after sign-in so the team can distinguish an approved connection from a usable authorized tool.
05 / Security review
Test failure conditions while the rollout is small.
Hooks make local decisions without waiting for a network request. During a temporary outage, a valid unexpired signed cache can remain usable.
Expiry and known revocation require different treatment. Required policy that is unavailable can cause covered critical gates to deny an operation.
This behavior is control-specific. Native hook errors or timeouts can permit execution, and unrelated execution paths retain their own failure behavior.
Required unknown-repository events use a bounded offline queue. Delivery problems produce diagnostics without preventing development work in that repository.
Neither unknown-repository mode automatically approves or onboards the repository. Company policy and reviewed registry hooks cannot block unapproved work.
Exercise recovery with a fresh session. Check cache validity, the selected release, native activation, and the actual permitted or prohibited operation.
A successful installation alone does not establish safe failure. Keep the observed outage behavior with the tested versions and boundary.
| Situation | Behavior to inspect | Review follow-up |
|---|---|---|
| Temporary loss of connectivity | Use of a valid unexpired cache and queued delivery | Distinguish cached operation from delivery of a new release |
| Required policy fails validation | Coverage degradation and denial at covered critical gates | Identify the precise affected operations |
| Revoked material is known | Rejection according to verified revocation state | Confirm how affected devices receive the state |
| Runtime artifact is absent | Diagnostics identify the signing dependency | Provide a usable variant before continuing setup |
| Native hook fails or times out | The host may allow execution | Decide whether that conditional behavior meets the requirement |
06 / Security review
Close the review with deployment evidence.
Ask for the selected architecture, reviewer permissions, signing operations, supported releases, and recovery responsibilities. Assign operational contacts before adding developers.
Review the report inventory with the data owner. Sanitized repository identities and internal resource names may still reveal organizational information.
Set deployment requirements for hosting, retention, deletion, incident communication, and third-party documentation. These pages do not supply invented commitments or certifications.
Run representative permitted and prohibited operations on the actual participating clients. Inspect execution results alongside diagnostics and reported events.
Connections and Sessions contain client-reported operational evidence. They do not independently attest the machine or establish observation of every execution path.
What does a valid signature establish?
It establishes verification of the signed artifact. It does not establish native activation or coverage of every operation on the device.
Can approved hooks bypass native permissions?
No. They can restrict operations at supported boundaries. Native approvals and external authorization continue to govern access.
Does this page establish a service guarantee?
No. Use deployment evidence and the applicable agreement to settle service levels, operational responsibilities, and required assurances.