What makes a security claim inspectable?
Source location, provenance, deterministic signals, threat context, integrity data, and the limits of the observation remain attached to the claim.
Security / Trust Center
Trust is a system property.
Aegis does not treat a model answer, browser redirect, or success message as proof. Security-sensitive state is tied to explicit authority, evidence, and independent checks.
Local-first where supportedExplicit authorizationIndependent verificationSigned release artifactsServer-side paid entitlement
TRUST BOUNDARIES
Small surfaces.
Explicit data paths.
The website keeps presentation separate from authorization. Billing, release identity, local execution, and independent verification each have a distinct authority boundary.
01Browser
→ Presentation, checkout UI, account UX
NOT ENTITLEMENT AUTHORITY02Billing API
→ Authenticated identity and ledger projection
SERVER-SIDE BOUNDARY03Runtime
→ Signed local developer execution surface
PINNED RELEASE IDENTITY04Verifier
Independent checks and evidence state
SEPARATE FROM PROPOSERSecurity proof questions
What counts as independent checking?
A verifier remains distinct from the system that proposed the security-sensitive action, while deterministic checks stay separate from model agreement.
Did the patch close the path?
Patch acceptance is not the target metric. Aegis asks whether the original failure stops reproducing without introducing a new failure.
METHODOLOGY
Every critical decision keeps its own authority.
Execution, verification, billing, and release integrity are related, but none is allowed to silently stand in for another.
Permission is separate from analysis.
Security-sensitive execution, repository mutation, and dynamic validation are not implied by a finding. Authorization remains a separate state.
The proposer does not certify itself.
Aegis keeps proposing and verifying roles distinct and preserves missing or conflicting evidence instead of flattening it into a clean result.
Checkout success does not mint access.
Paid capability is derived from authenticated identity and authoritative server-side billing state. Paddle webhooks are signature-verified before they can affect entitlement.
Runtime artifacts are identity-checked.
The extension manages a signed proprietary Aegis Runtime in VS Code global storage. It verifies the signed runtime manifest against a pinned Ed25519 release key and verifies the selected artifact with SHA-256 before install or reuse. The extension starts the runtime on loopback for the local developer surface.
PUBLIC ATTACK SURFACE
Presentation is not authority.
The website uses restrictive production headers, keeps server secrets out of browser code, and separates public presentation from billing and entitlement authority.
BrowserPresentation, checkout UI, account UXNot entitlement authority
Billing APIAuthenticated identity and ledger projectionServer-side boundary
Paddle webhookRaw-body signature verification and replay controlsExternal billing evidence
ExtensionLocal developer surface and capability proof consumerCannot mint paid proof
RESPONSIBLE DISCLOSURE
Found a vulnerability?
Report it privately. Include the affected version, release, commit, or URL, a concise impact description, reproduction steps, and the minimum safe evidence needed to reproduce it. Do not include secrets or another user's private data.
Good-faith research is welcome on systems you own or are explicitly authorized to test. Production denial-of-service, high-rate testing, social engineering, destructive actions, and unauthorized third-party testing are outside the policy.