Trust & Security

Processes you can verify

Magertron's job is to control what AI agents can do and what they spend. The same discipline runs through how the product itself is built: access, change, and operations controls are structural, technical, and live in the code — mapped here against the nine SOC 2 Common Criteria families.

SOC 2 readiness in progress — this is a map, not an attestation

All nine Common Criteria families are authored, with five fully covered by strong, written controls. The status below reflects how thoroughly each family is addressed in product and documentation today — not independent auditor verification. We state where we are honestly, including where the work is still maturing.

Coverage across CC1–CC9

Each family below names what Magertron does — in product or in a written control narrative — that bears on that criterion. Green means a strong, often end-to-end-verified control exists. Amber means the technical pieces are in place while the organizational or evidence layer matures.

5 families fully covered 2 substantially covered 2 maturing 0 unaddressed
CC6 Logical & Physical Access Strong

The deepest area. BYOK credentials are referenced, never held — proxy-injected, per-namespace tenant isolation, never logged. OIDC id_token verification against a live IdP, SCIM provisioning with deny-by-construction isolation, and per-tool RBAC. Physical access inherited from the cloud provider.

CC8 Change Management Strong

An eight-stage gated release pipeline with dev/prod channel separation, a mandatory peer-review merge gate, build provenance pinned to the commit SHA, and a per-release receipt. A build can no longer ship itself to customers.

CC4 Monitoring of Controls Strong

A complete OCSF audit trail (RAII-guaranteed), exactly-once metering, and tool-definition drift detection — readable in Splunk for continuous visibility. A scheduled detector counts failed-auth and denied-tool events and pushes deduplicated alerts over threshold.

CC5 Control Activities Strong

Built on structural enforcement, deny-by-construction, least authority, and defense-in-depth. A control-activity matrix classifies every control by risk, type, layer, and mode, doubling as the index to the full control set.

CC7 System Operations Strong

Scoped to build-and-release, since customers run Magertron themselves. Content-hash drift / rug-pull detection, an audit trail integrated to Splunk, a written supply-chain incident-response and disclosure procedure, and offsite backups with verified restore.

CC2 Communication & Information Covered

A strong information layer (audit trail, metering, drift detection feed governance reviews), a written vulnerability-disclosure procedure, a customer-notification commitment, a dedicated security contact, and published trust documentation.

CC3 Risk Assessment Covered

A documented methodology — likelihood × impact scoring with mitigate / accept / monitor treatment — and a living Risk Register of scored, owned, tracked risks reviewed on a quarterly cadence alongside control-monitoring and vendor reviews.

CC9 Risk Mitigation Maturing

A two-tier vendor register with per-vendor risk and compensating control, on an annual-plus-on-change review cadence. Source and secrets in recoverable custody with verified offsite restore. Maturing: a second review cycle and bound insurance.

CC1 Control Environment Maturing

A code of conduct, documented organizational structure, an accountability model evidenced by the audit trail, and hiring and onboarding policy. The honest gap — independent oversight — is named as a maturity item rather than papered over.

Enforcement that lives in the product

The strongest families are strong because the control is structural — it is enforced by the architecture, not by a policy a person has to remember to follow.

🔑 Credentials referenced, never held

Bring-your-own-key credentials are injected at the proxy and isolated per namespace. Magertron never stores them in plaintext and never writes them to logs.

  • Per-namespace tenant isolation
  • OIDC id_token verified against a live IdP
  • SCIM provisioning, deny-by-construction
🚦 A build can't ship itself

Every release passes an eight-stage gated pipeline with a mandatory peer-review merge gate and dev/prod channel separation, with provenance pinned to the commit SHA.

  • Per-release receipt for traceability
  • Fix-through-the-pipeline incident response
  • Source & artifacts backed up offsite, restore verified
📡 Continuous, queryable monitoring

A complete OCSF audit trail is guaranteed by construction and streamed to Splunk. A scheduled detector watches for failed-auth and denied-tool spikes and alerts over threshold.

  • Exactly-once metering
  • Tool-definition drift / rug-pull detection
  • Alert path exercised by the release regression suite
🛡️ Per-tool authority, by default

Access is least-authority and deny-by-construction: a caller gets exactly the tools their role grants, enforced at the gateway before a request ever reaches a server.

  • Per-tool RBAC at the data plane
  • Inventory token authority-split
  • Structural enforcement over policy reminders

Report a vulnerability

We welcome responsible disclosure. If you believe you've found a security issue in Magertron, contact us directly — we commit to acknowledging reports and keeping affected customers informed as we investigate and remediate through the gated pipeline.

Security contact
Machine-readable
Disclosure policy

This page is a navigational summary of Magertron's control posture, offered for security and compliance reviewers. It is not a SOC 2 attestation, a readiness assessment, or a statement of compliance — those require a qualified auditor, defined Trust Services Criteria scoping, and evidence collected over a defined period. The status shown reflects documentation and product coverage as of today. Magertron is licensed software that customers deploy on their own infrastructure; the system in scope for these criteria is Magertron's build-and-release operation, not a hosted service.