Security Built on Verifiable Boundaries
MY OWL is engineered for security-conscious development teams. We document our actual security controls, write contracts, and architectural invariants truthfully.
GitHub App Authentication & Scopes
MY OWL connects via an official GitHub App rather than personal access tokens. Scopes are strictly restricted to read repository contents/metadata and write pull requests exclusively to isolated migration branches.
Installation State Binding & Webhook HMAC
Installation flows generate single-use, cryptographically signed state tokens with 15-minute expiration to prevent cross-site request forgery and installation hijacking.
Controlled Write Safety Contract
Every proposed modification is validated by a strict ControlledWriteRequest contract in core before any Git operation is executed. Direct commits to default branches are programmatically impossible.
Baseline Integrity & Divergence Protection
Scans record the exact 40-character Git commit SHA of the target branch. If your default branch HEAD moves before a proposal is created, the system refuses to push.
OPERATIONAL INVARIANTS
Security Invariant Matrix
Strict execution boundaries enforced by our GitHub App write contracts and platform architecture.
| Operation / Capability | Enforcement | Status | Implementation Detail |
|---|---|---|---|
| Source Code Inspection | Read-only AST traversal | Implemented | Code is read into memory buffers, parsed into AST nodes by ts-morph, and analyzed for symbol reachability. |
| Default Branch (main/master) Commits | Strictly forbidden | Blocked | MY OWL has no permissions to write directly to default branches. Proposals must target isolated branches. |
| Auto-Merging Pull Requests | Strictly forbidden | Blocked | No auto-merge capability or permissions exist. Every proposal stops at a GitHub Draft PR for human review. |
| Branch Creation Scope | apiproof/* and myowl/* only | Enforced | Validated against canonical branch naming policy. Custom or unapproved branch prefixes are rejected. |
| Patch Scope Boundary | Affected file lines only | Enforced | Rejects patches modifying files outside the target finding or touching workflow configuration files. |
| Pre-Proposal Verification | 4-gate compiler harness | Enforced | Syntax check, TypeScript compiler diagnostics, scope boundaries, and dry-run tests must pass before PR creation. |
| Data Persistence | Metadata, findings & plans only | Implemented | Database stores repository metadata, baseline SHAs, finding snippets, and verification reports. |
| Self-Hosted Runners / Private VPC | Execution in customer perimeter | Planned | Architecture supports runner decoupling; dedicated self-hosted test execution is on the roadmap. |
| Enterprise SSO / SAML | Corporate identity integration | Planned | Currently supports GitHub OAuth session auth; SAML/Okta integration is on the roadmap. |
What We Store and What We Discard
We believe in radical transparency about data boundaries. We do not make vague marketing claims; here is exactly what our database holds.
- • Repository identity (GitHub ID, full name, default branch name)
- • Baseline commit SHA (40-char hex string)
- • Finding metadata: file path, line number, AST symbol, and minimal source snippet around the affected call site
- • Deterministic MigrationPlan JSON & patch diff text
- • Verification evidence digests & execution reports
- • Audit logs of scan events and proposal creations
- • Full repository source trees or unimpacted files
- • Customer environment variables or .env secrets
- • Customer database passwords or production API keys
- • Private keys (stored in encrypted server environment only)
- • We do not train machine learning models on customer code