Security
Nothing changes without your control.
Glomancy is designed so action is authorized, visible, and reversible. The sections below describe architectural intent. Concrete guarantees will be published when implementation details are confirmed.
No certifications or compliance claims are made here. Language remains architectural until production security details are supplied.
01
Action authorization
Architectural intentSensitive operations should be gated behind explicit approval rather than silent mutation.
02
Controlled execution
Architectural intentTool and action permissions are intended to constrain what Glomancy can touch in a project.
03
Change visibility
Architectural intentOperational evidence is meant to show what ran, what changed, and what was verified.
04
Inspectable mutation
Architectural intentChanges should be reviewable before they land — not blind writes into production content.
05
Snapshots
Architectural intentSnapshot concepts support restore points around meaningful change sets.
06
Rollback
Architectural intentRollback is part of the control model when a change needs to be reversed.
07
API keys
Architectural intentKey handling is treated as a first-class control surface. Exact storage and transport mechanics will be documented when finalized.
08
Bring your own key
Architectural intentBring-your-own-key patterns are part of the intended architecture so teams retain provider credential ownership.
09
Data handling
Architectural intentProject data handling policies will be stated precisely once implementation and retention rules are confirmed. No guarantees are implied here.
10
Provider communication
Architectural intentProvider routing should remain explicit and controllable. Payload and boundary details will be documented with the production architecture.