unbounded writes
Agents writing where they should not
Path scope is declared in the approval contract. Anything outside the declared scope is treated as out of bounds and rejected at validation time, before any write.
Security posture
Security
Latchpoint is built with least-privilege intent, conservative defaults, and an emphasis on auditable behavior. Scope stays intentionally narrow and is declared in the approval contract. This page describes the actual posture in plain terms, including what it does not address.
Defended against
What the control layer prevents
partial writes
Repository half-modified by a failed step
Approved changes are applied using atomic file replacement with post-write verification. A failed step rolls back cleanly instead of leaving partial writes behind.
silent failure
Failures that disappear from view
Every proposal, validation result, approval, block, and write produces a recorded artifact. Failed and blocked changes are recorded honestly alongside successful ones.
implicit rules
Rules buried in prompts
Scope, permissions, and operating limits are declared in the approval contract rather than in agent instructions. Validation checks the contract, which is inspectable, instead of trusting that the prompt was followed.
Not claimed
What this posture does not cover
Stated explicitly so the system is not asked to do things it was not built to do.
- No compliance certifications are claimed. Where a certification exists, it will be documented explicitly or not mentioned at all.
- No defenses are claimed against denial-of-service, network-level attacks, supply-chain compromise of dependencies, or zero-day exploits in the underlying platform.
- No claim that the control layer protects against human error in the approval contract itself. The contract is the source of truth; if it is wrong, the system enforces the wrong thing.
- No replacement for code review, CI, or human engineering judgment. Latchpoint operates alongside those, not in place of them.
- No absolute privacy guarantees beyond the operational posture described on Privacy.
Operational discipline
How the system itself is run
least privilege
Narrow scope by default
Repository permissions stay narrow by default. The integration requests only what is needed to operate the control layer, and the scope is declared in the approval contract.
no payload dumps
Webhook bodies are not logged
Operational telemetry records event types and identifiers, not full webhook payloads. Repository identifiers appear as short, de-identified references.
no token exposure
Auth never reaches logs
GitHub tokens and auth headers are excluded from logs and from any debug output. Secrets live in runtime secret management, not in source control.
audit by default
Decisions are recorded in the flow that produced them
The audit trail is part of the same code path that validates and applies a change, not a separate logging layer running alongside it. Approvals, blocks, and rollbacks all leave records in the same place.
Access
Removing the integration
Admins can remove integration access from their GitHub settings at any time. Removal is immediate and does not require coordination with Latchpoint to take effect. There is no offboarding flow to wait on; revocation is in the admin's hands.
Reporting
If you believe you have found a security issue, please review our responsible disclosure policy for guidance on what to report and how reports are handled.