Security
Controls, not assurances.
AXIS Core underpins every business in the AXIS estate, which makes its security posture everyone’s concern rather than its own. What follows is what the platform does — behaviour you could read in the code or observe at a boundary — rather than a list of adjectives.
- Request
- G1Session verifiedDeny by defaultRefusedUnverifiable session
- G2Authorized for this resourceAuthorization per resourceRefusedNot permitted
- G3Audit record writtenAudit before completionRefusedAudit store unavailable
- Action completes
Control register
Six controls, stated as behaviour.
SC-01
Deny by default
Access is refused unless it is positively established.
Authentication is verified server-side and role claims are never trusted from the client. An unverifiable session, a missing provider or an unreachable dependency all resolve to refusal. There is no configuration that turns a missing check into a granted one.
SC-03
Audit before completion
A privileged action that cannot be recorded does not happen.
Privileged actions are written to durable audit as part of the action, not after it. If the audit store is unavailable the action is refused rather than performed unrecorded, because an unlogged privileged action is indistinguishable from an unauthorized one.
SC-04
Secret custody
Credentials are held centrally, scoped narrowly, and rotatable.
Secrets are issued least-privilege and scoped to the single zone, store or service that needs them. Rotation and revocation paths are exercised rather than assumed, and a credential is never widened to unblock a deployment.
SC-05
Enforced boundaries
Public and protected surfaces are separated by the platform.
Private surfaces are held to no-store and noindex by contract rather than convention, and a public route is never placed in front of a protected one. Boundary behaviour is asserted at release against raw responses, not through a browser that would follow a redirect and appear protected either way.
SC-06
Release gates that fail closed
Verification blocks the release rather than warning about it.
Security and integrity checks run as gates that fail the deployment. A release is promoted from a verified artefact and can be rolled back to a known-good one; a check that cannot run is treated as a check that did not pass.
Coordinated disclosure
Found something? Tell us before you tell the internet.
Reports use the private intake pathway, not a published mailbox. Choose Security / Vulnerability Disclosure on the inquiry channel, verify your email address, and the report is routed privately to the AXIS owner responsible for security. There is no bug bounty — none is funded, and advertising one we could not honour would waste your time.
Do not include live credentials, private keys, customer data or destructive proof-of-concept material.
- 01
Report privately
- Report privately through the inquiry channel first, and give a reasonable window before publishing.
- Include enough detail to reproduce the finding.
- Do not access, modify or retain data that is not yours.
- 02
Acknowledged and scoped
We acknowledge your report and tell you whether it is in scope.
- 03
Kept informed
We keep you informed while a confirmed issue is being fixed.
- 04
Credited
We credit you when a report leads to a change, if you want credit.
- In scope
- Anything served from axis-core.dev, and any AXIS Core infrastructure you reach through it.
- Out of scope
- Findings that require physical access, social engineering of staff, or denial-of-service testing against production.
Next
What these controls protect.
AXIS Core underpins every business in the AXIS estate. The ecosystem shows each of them, and the planes each one draws on.