> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/ship/security-and-controls.md).

# Operate Ship Safely

Security, permissions, environment, evidence, and human-review controls for running Ship in an engineering organization.

## Quick answer

Give Ship the smallest environment and provider access that supports the workflow. Separate authentication from repository authorization, use isolated test identities and data, preserve immutable run evidence, and keep people responsible for generated coverage, suggested fixes, and release decisions.

## Environment controls

* Prefer staging or QA over production.
* Use disposable data and reset it on a documented cadence.
* Limit the test identity to the roles and actions required by the evaluation.
* Do not grant payment, messaging, deletion, or integration access unless the scenario explicitly requires it and safeguards exist.
* Record the endpoint, build, data revision, browser, region, and identity used for each decision-bearing run.

## Repository controls

* Treat sign-in and repository authorization as separate decisions.
* Prefer selected repositories over all repositories.
* Confirm the organization, repository, default branch, and webhook or check scope.
* Remove access when the evaluation ends.
* Never place private keys, tokens, customer records, or unrelated repositories into prompts, screenshots, tickets, or public documentation.

## Integration controls

| Integration      | Start with                | Verify before automation                                                 |
| ---------------- | ------------------------- | ------------------------------------------------------------------------ |
| GitHub or GitLab | One evaluation repository | Read/write permissions, branches, checks, and installation ownership     |
| Jira or Linear   | One project or team       | Issue types, labels, transitions, comments, and eligible bug rules       |
| Slack            | One controlled channel    | Which findings are posted and whether sensitive evidence is excluded     |
| MCP client       | One named evaluator       | OAuth identity, available tools, organization boundary, and auditability |

## Human review checkpoints

A person should review:

* The application and repository boundary
* The crawler's allowed actions and stopping conditions
* Generated modules, journeys, requirements, and tests
* Change-impact confidence and fallback coverage
* Bug reproduction and root-cause hypotheses
* Any suggested code change
* The evidence package used for a release decision

Ship may initiate and coordinate quality work, but it does not silently merge code, approve generated tests, apply a suggested fix, or own a release decision.

## Interpret incomplete outcomes correctly

Use explicit states:

* **Passed** — required checks completed and supporting evidence is available.
* **Failed** — a tested expectation did not hold.
* **Blocked** — an external condition prevented the workflow from completing.
* **Partial** — some planned analysis or execution completed, but required evidence is missing.
* **Unknown** — the system cannot establish the result from available evidence.

Never convert a blocked, partial, unknown, zero-test, or evidence-free outcome into a pass.

## Trial closeout checklist

* Export or retain the evidence needed for the evaluation record.
* Record which workflows were validated and which remained untested.
* Review generated tests before moving them into shared suites.
* Remove unused provider and integration permissions.
* Disable or delete disposable test identities and data according to policy.
* Name the owner for continued monitoring before choosing a paid plan.

Return to [Ship by ContextQA](/ship/ship.md) or continue with [Run Ship workflows](/ship/workflows.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/ship/security-and-controls.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.