Security
What Stenlio can reach, and what it keeps
One repository, one website, one writable directory, and a copy of what it read so a claim can be traced to its evidence. Everything below describes the shipped product.
Last substantive change:
GitHub permissions
- Installation scope
- One private repository, and this is enforced rather than assumed: an installation that grants access to more than one repository, to none, or to a public one is refused outright (SELECT_EXACTLY_ONE_REPOSITORY) instead of Stenlio choosing one for you.
- Contents: write
- Required to create a branch and commit an article file. GitHub scopes this permission repository-wide — it cannot be narrowed to a directory.
- The directory limit
- Because GitHub cannot express it, the limit to your registered content directory is enforced by an application guard that re-derives the path against the registered root immediately before every write, and again inside the approval transaction.
- Pull requests: write
- Required to open the draft pull request. `draft: true` is not configurable anywhere in the product; the pull request targets a branch Stenlio generated, never your default branch, and nothing in the codebase can merge it.
- Revoking
- Revoke the content surface to stop writes, or uninstall the GitHub App to stop reads. A revoked surface removes the row the approval query depends on, so approval fails closed rather than being approved and then blocked.
| Permission | Why, and how far it reaches |
|---|---|
| Installation scope | One private repository, and this is enforced rather than assumed: an installation that grants access to more than one repository, to none, or to a public one is refused outright (SELECT_EXACTLY_ONE_REPOSITORY) instead of Stenlio choosing one for you. |
| Contents: write | Required to create a branch and commit an article file. GitHub scopes this permission repository-wide — it cannot be narrowed to a directory. |
| The directory limit | Because GitHub cannot express it, the limit to your registered content directory is enforced by an application guard that re-derives the path against the registered root immediately before every write, and again inside the approval transaction. |
| Pull requests: write | Required to open the draft pull request. `draft: true` is not configurable anywhere in the product; the pull request targets a branch Stenlio generated, never your default branch, and nothing in the codebase can merge it. |
| Revoking | Revoke the content surface to stop writes, or uninstall the GitHub App to stop reads. A revoked surface removes the row the approval query depends on, so approval fails closed rather than being approved and then blocked. |
The honest caveat, stated rather than buried: repository-wide contents-write is a GitHub constraint, not a Stenlio design choice. The directory limit is an application guarantee, and the guard that enforces it runs on both sides of the approval — once when you approve, once at the write.
What is stored, and for how long
- Source snapshots
- Repository trees, sampled file contents, and crawled page HTML are written to a private object bucket, keyed by a hash of their own content. This is a copy held by Stenlio, not a pointer into your systems.
- Database
- Holds the pointer, the content hash, a bounded summary, and a status — never the raw payload in a column.
- Retention
- Deleting a company disables workflows, revokes content authorisation, deletes credential references, and cancels queued work before any external call. Source objects and snapshots are deleted within 30 days.
- Credentials
- Per-company integration credentials are encrypted and unreachable from models, browser clients, logs, and every other company on the platform.
- Analytics data
- Stripe and PostHog are read as aggregate snapshots. No card data, no payment methods, no raw customer records, no session recordings.
- Your repository
- Stays in GitHub, under GitHub’s access control. Stenlio never creates a public mirror or a Stenlio-hosted copy, and never deletes a repository or a pull request.
| Data | Where it lives |
|---|---|
| Source snapshots | Repository trees, sampled file contents, and crawled page HTML are written to a private object bucket, keyed by a hash of their own content. This is a copy held by Stenlio, not a pointer into your systems. |
| Database | Holds the pointer, the content hash, a bounded summary, and a status — never the raw payload in a column. |
| Retention | Deleting a company disables workflows, revokes content authorisation, deletes credential references, and cancels queued work before any external call. Source objects and snapshots are deleted within 30 days. |
| Credentials | Per-company integration credentials are encrypted and unreachable from models, browser clients, logs, and every other company on the platform. |
| Analytics data | Stripe and PostHog are read as aggregate snapshots. No card data, no payment methods, no raw customer records, no session recordings. |
| Your repository | Stays in GitHub, under GitHub’s access control. Stenlio never creates a public mirror or a Stenlio-hosted copy, and never deletes a repository or a pull request. |
Every source Stenlio reads
- GitHub repository (Required)
- Repository metadata, the registered blog directory, PR and check state. Source only transiently, and only as a pull request requires.
- Primary website (Required)
- Public pages, technical and content inventory, indexability, and the citations behind every finding.
- Blog directory (Required)
- Existing articles, canonical URLs, internal-link context. The only directory Stenlio may write to.
- Stripe (Optional)
- Aggregate revenue, subscription, refund, and churn measurements. Never card data, payment methods, or raw customer records.
- PostHog (Optional)
- Approved aggregate product queries and saved-insight results. Never raw event streams or session recordings.
- Search Console (Optional)
- Query, page, click, impression, position, and indexability measurements.
| Source | What it collects |
|---|---|
| GitHub repository (Required) | Repository metadata, the registered blog directory, PR and check state. Source only transiently, and only as a pull request requires. |
| Primary website (Required) | Public pages, technical and content inventory, indexability, and the citations behind every finding. |
| Blog directory (Required) | Existing articles, canonical URLs, internal-link context. The only directory Stenlio may write to. |
| Stripe (Optional) | Aggregate revenue, subscription, refund, and churn measurements. Never card data, payment methods, or raw customer records. |
| PostHog (Optional) | Approved aggregate product queries and saved-insight results. Never raw event streams or session recordings. |
| Search Console (Optional) | Query, page, click, impression, position, and indexability measurements. |
The boundary in one list
- Your repository stays yours: The GitHub App is installed on one repository you select. Stenlio never creates a public mirror or a Stenlio-hosted copy, and collaborators reach your source through GitHub as they always did.
- Writes are guarded before every request: GitHub’s contents-write permission is repository-wide, so the registered blog directory is enforced by an application guard immediately before each write rather than by a GitHub permission boundary.
- Credentials are out of reach: Per-company credentials are encrypted and inaccessible to models, browser clients, logs, and every other company on the platform.
- Analytics stay aggregate: Stripe and PostHog default to read-only aggregate snapshots and source provenance. No card data, no payment methods, no raw customer records, no session recordings.
- Deletion is a real path: Deleting a company disables workflows, revokes authorisation, deletes credential references, and cancels queued work before any external call. Source objects and snapshots go within 30 days.
- Your artefacts survive you leaving: Cancelling ends new execution at the end of the paid period and leaves analysis readable. Stenlio never deletes your GitHub repositories or pull requests.
What Stenlio cannot do
- Merging, publishing, or deploying anything
- Writing anywhere outside the registered content directory
- Sending email, posting to social, or spending on ads
- Moving money, issuing refunds, or changing a price
- Modifying infrastructure or running database migrations
These are absent capabilities, not permissions you have withheld. There is no plan, setting, or approval that turns them on today. The one action that does exist behind an approval is opening a draft pull request — see the approvals guide.