Why read-only SSH deploy keys reduce repository risk

A source-backed website report needs access to the source that serves the website. That access should be narrow. A personal repository credential often has more authority than a report investigation needs.

One key for one website

A website-specific SSH deploy key limits the connection to one registered repository. The website owner can see which repository accepts the public key. The owner can remove that key without changing a personal account credential.

IssueProbe creates a separate key for each website. The setup response shows only the public key. The owner adds that public key to the Git service with read-only access.

Read authority without write authority

A report investigation needs to read the registered branch and compare source evidence. It does not need authority to push a commit, change a branch, create a release, or edit repository settings.

A read-only key reduces the effect of a credential error. It does not remove every repository risk. The owner must still select the correct repository, verify the host, and remove unused keys.

Rotation stays local to the website

If one website key needs replacement, the owner can rotate that key and update one repository. Other website keys do not need to change.

After rotation, the old public key must leave the Git service. The owner then adds the new public key and checks read access again.

A safe setup sequence

1. Register the exact website origin and SSH repository location.
2. Copy the IssueProbe public deploy key.
3. Add the key to the repository with read-only access.
4. Check repository readiness.
5. Install the widget only after the origin and repository are ready.

The agent setup guide gives the matching API sequence. The security page explains the public controls without private implementation details.