Frequently asked questions
GoSentrix is the independent security verification body for software delivery. These answers are written to stand on their own: what GoSentrix is, how verification works, what AI can and cannot authorize, and where the company stands today.
GoSentrix is the independent security verification body for software delivery. It determines whether security evidence has earned the authority to support an action — proceed, stop, escalate, suppress, disprove, or accept risk. It operates across code, merge, release, and runtime.
No. ASPM platforms aggregate and prioritize findings. GoSentrix sits one layer above that: it determines whether security evidence has earned the authority to enforce, clear, or stop a release. Prioritization is a ranking function; verification is a judgment function. GoSentrix does the second.
No. GoSentrix does not produce findings of its own. Scanners, AI agents, and runtime tools produce signals. GoSentrix treats those signals as unverified claims and determines what they are allowed to enforce.
GoSentrix uses AI inside the verification process, but it is not an AI-judgment product. AI signals enter the evidence ladder as claims, not as authority. They cannot terminate the ladder on their own. The line we hold: AI can be probabilistic, but security authority cannot be.
GoSentrix produces decisions — readiness assessments, release decisions, fix verifications, override authorizations — each bound to the evidence and policy version active at the time it was made, and each designed to be replayed and defended later.
Fortune 2000 security organizations operating modern software delivery — where AI agents write and review code, scanners produce findings faster than analysts can promote them, and audit requirements demand defensible decisions. Specifically: CISOs, AppSec leads, platform engineering leaders, and audit/GRC teams.
A security verification body is an independent layer between the tools that produce security signals and the systems that act on them. It determines which signals can promote into evidence, whether that evidence can justify enforcement, and whether the resulting decision can be replayed, audited, and defended later.
AI agents, scanners, runtime systems, and policy engines now generate more security claims than teams can govern. The problem is no longer detection — it is authority. Teams need to know which evidence has earned the right to enforce, clear, or stop a release. A verification body answers that question and produces a record that can be defended later.
A security platform aggregates capabilities — scanning, prioritization, ticketing, reporting. A verification body is a category of judgment, not a category of features. Its job is not to do more security work but to determine whether the security work that has been done is enough to support the action being requested.
Prioritization ranks findings by likelihood or impact. Verification determines whether the evidence behind a finding has earned the authority to enforce. A high-priority finding without sufficient evidence cannot hard-block. A low-priority finding with strong corroborating evidence can. The bar is evidence, not severity.
A standard CI/CD security gate evaluates findings against a threshold and passes or fails. A verification body evaluates the evidence behind those findings against a policy version, promotes evidence through governed states, downgrades its own authority when proof is missing, and produces a replayable record. The gate is the surface; the verification body is what runs underneath it.
It is a new category. The verification body sits at a different altitude than ASPM, scanners, or runtime tools. None of those products do what a verification body does: independently determine whether security evidence has earned the authority to act on it. The category exists because the authority problem exists.
Evidence earns authority when it is strong enough, current enough, corroborated enough, and replayable enough to meet the organization's own standard for the action being requested. The bar is not severity, scanner confidence, or AI judgment. It is whether the evidence supports the decision and whether the decision can be defended later.
Findings move through governed evidence states — detected, observed, corroborated, validated — before they can become authoritative. Promotion happens on independent corroboration from multiple sources. Promotion strength is a function of source diversity, not signal count. Two findings from the same scanner do not double the confidence.
Suppression dismisses a finding from view. Disproval refutes it with evidence. GoSentrix makes the distinction structurally: disproval requires either an artifact reference or a reviewer attestation that evidences the finding does not apply in context. A finding cannot be marked disproven without that evidence.
A consequential decision is replayable when it can be reproduced against the evidence, artifacts, trust state, freshness state, and policy version active at the time it was made. Replay proves reproducibility, not correctness — but reproducibility is what makes a decision a decision rather than an opinion.
GoSentrix downgrades its own authority. If a decision requests HARD_BLOCK without sufficient evidence to support it, the system automatically narrows the decision to a lower level and records the downgrade reason. The operator cannot reverse the downgrade without supplying the missing evidence.
Every consequential decision is bound to the policy version active at the time it was made. Later policy edits do not retroactively change a past decision's authority. This is the structural difference between "we changed the rules" and "we re-graded what happened under the old rules."
Overrides flow through typed approval chains with dual control. Business-critical overrides require VP approval. Risk-acceptance overrides require CISO approval. Trust-boundary violations require CISO-level break-glass and cannot be approved at a lower tier. AI agents cannot grant overrides.
The operator action is recorded as evidence input to the next verification round, not as terminal closure. GoSentrix re-executes the original replay command against the new artifact and compares outcomes. If the replay still produces the original behavior, the fix did not work — regardless of what the ticket says. A closed ticket is not evidence that risk was removed.
GoSentrix manifests operationally as a security decision control plane integrated across code, merge, release, and runtime. At each surface it does the same four things: ingests signals, promotes evidence under doctrine, evaluates evidence against the active policy version, and emits a decision that can be replayed and defended later.
Yes. At every pull request, GoSentrix takes scanner findings, AI-agent claims, and prior-decision context as unverified inputs, promotes the evidence under doctrine, evaluates it against the active policy version, and produces a merge readiness decision — PASS, WARN, SOFT_BLOCK, or HARD_BLOCK — with a signed proof record.
Yes. At release, GoSentrix aggregates per-service decisions into a workspace-scope decision with collective evidence references and a signed bundle. The workspace decision is its own decision, not the worst per-service verdict. License and supply-chain release eligibility runs as a parallel decision axis with its own gate.
Yes. When a developer marks a finding fixed, GoSentrix re-executes the original replay command against the new artifact and compares outcomes. Three outcomes only: vulnerability absent, vulnerability present, or indeterminate. Indeterminate is preserved as first-class — it is not auto-promoted to fixed.
Yes, in the sense that runtime telemetry is one of the evidence sources GoSentrix verifies against. Runtime signals enter the evidence ladder as unverified claims and can corroborate findings, contribute to fix verification, and inform downgrades when expected behavior is not observed.
AI-provenance signals are captured at the developer surface via hooks that record AI lineage at session-start and post-edit events. The lineage is persisted as evidence. AI claims about code safety enter the evidence ladder capped at the DETECTED level — they can contribute to corroboration but cannot terminate the ladder without independent non-probabilistic evidence.
No. Scanners, AI agents, and runtime tools produce signals. GoSentrix treats those signals as unverified claims and determines what they are allowed to enforce. It does not produce findings of its own, and it does not replace the sources it verifies.
No. GoSentrix verifies whether the available evidence is strong enough to support the action being requested. Risk appetite — the standard the evidence is judged against — is the organization's decision, not GoSentrix's.
No. We do not make incident-prevention guarantees. We make verification claims: that decisions are bound to the evidence and policy active at the time, that they can be replayed, and that the verification body downgrades its own authority when proof is missing.
No. False-positive elimination is not a claim our doctrine permits. What GoSentrix does is distinguish disproval (evidence that a finding is invalid in context) from suppression (dismissal without evidence). The two are structurally different terminal states.
GoSentrix verifies fixes within supported evidence paths. It does not guarantee remediation worked in every case. A re-run that does not fail is one piece of evidence; it is not closure. Indeterminate outcomes remain indeterminate until further evidence supports a state transition.
No. Operator actions on findings — dismiss, mark fixed, accept risk — are recorded as evidence inputs to the next verification round. Disproval of complex findings often requires reviewer attestation. The verification body does not eliminate human judgment; it ensures human judgment leaves a record.
No, not yet. Verification architecture is implemented. Field-proven authority requires a linked customer field event — a documented case with prevented outcome, replay artifact, customer attestation, and legal review. Until that event is on record, we do not claim field-proven status. When it is, this page will reflect it.
We do not claim incident prevention in customer environments until a customer field event is recorded. Doing so would violate the same evidence doctrine our product enforces. When that evidence exists, we will publish it with the customer reference, the decision record, and the replay artifact.
Evidence promotion under governed states. Disproval as structured evidence rather than suppression. Self-downgrade when required proof is missing. Policy-version binding at decision time. Workspace-scope decision aggregation. AI-provenance capture at the developer surface. Pipeline BOM v1.
Pipeline-wide cryptographic signing rollout. Replay coverage across all consequential decisions; architecture is complete and full coverage is in progress. Field-proven authority. Customer-prevented-incident evidence. CycloneDX export for Pipeline BOM.
Because the verification body category requires it. Every claim GoSentrix makes about itself is assigned an evidence status — the same way every finding GoSentrix evaluates is assigned an evidence level. A claim cannot appear on a surface that demands more evidence than the claim has earned. We apply the rules to ourselves first.
