Frequently asked questions
What GoSentrix is, how verification works, what AI can and cannot authorize, and where the company stands today.
GoSentrix is release-evidence verification software for consequential software delivery. It qualifies evidence from existing security, engineering and workflow systems, evaluates that evidence against versioned customer policy and preserves the basis for explicit release decisions.
No. ASPM platforms aggregate, correlate, and prioritize application-security risk. GoSentrix is release-evidence verification software. It can consume signals from ASPM, scanners, SCA, SAST, CI, cloud, runtime, ticketing, and AI coding systems, then determine whether the evidence satisfies customer-defined policy for a release decision.
No. GoSentrix does not produce findings of its own. Scanners, AI agents, test systems and workflow tools produce signals. GoSentrix treats those signals as claims and determines whether they are strong enough to support a release decision.
GoSentrix can verify AI-generated claims, but it is not an AI-judgment product. AI signals enter as probabilistic claims and cannot terminate verification on their own. The principle we apply: Evidence can be uncertain. Policy evaluation must be reproducible, and insufficient evidence must be escalated.
GoSentrix produces explicit outcomes for release decisions — proceed, stop, escalate, or require authorization — each bound to the evidence and policy version active at the time it was made, and each preserved so it can be reviewed later.
Organizations that ship consequential software — where a release decision must be explainable after it is made. This includes founders, security and engineering executives, regulated-software leaders, AI and software governance leaders, and the teams that support them.
A team should use GoSentrix alongside an ASPM platform when it needs to verify that remediation evidence satisfies policy, bind release decisions to a versioned policy record, and preserve the basis for decisions that may be questioned later. ASPM helps decide what to fix; GoSentrix determines whether the evidence supports shipping.
Release-evidence verification is the practice of determining whether the available evidence satisfies customer-defined policy for a specific software release decision. It asks: what evidence supports the decision, what policy was applied, who accepted any residual risk, and can that basis be explained later?
Modern software delivery depends on more claims than teams can govern: tickets closed, vulnerabilities remediated, controls passed, exceptions approved, AI-generated changes reviewed, releases cleared. Those claims are distributed across tools, teams and time. Release-evidence verification determines which claims have earned the right to support a consequential decision and preserves the basis for that decision.
Vulnerability prioritization ranks findings by likelihood or impact. GoSentrix determines whether the evidence behind a finding has earned the authority to support a release decision. A high-priority finding without sufficient evidence cannot justify stopping a release. A low-priority finding with strong corroborating evidence can. The bar is evidence, not severity.
A standard CI/CD gate evaluates findings against a threshold and passes or fails. Release-evidence verification evaluates the evidence behind those findings against a policy version, promotes evidence through governed states, escalates when proof is missing, and preserves a decision record. The gate is the surface; verification is the judgment underneath it.
It is a focused category: release-evidence verification. ASPM, scanners, and runtime tools produce and prioritize signals. GoSentrix determines whether the evidence satisfies customer-defined policy for a consequential release decision. The category exists because the evidence problem in release decisions exists.
Proof requires independent evidence that the original risk is no longer present in the new artifact. This typically includes a retest with the original scanner or test, a reviewer attestation with artifact references, and corroboration from a second source. The only honest outcomes are risk absent, risk present, or indeterminate.
Evidence earns authority when it is strong enough, current enough, corroborated enough, and reviewable 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 explained 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 reviewable when the evidence, policy version, and reasoning behind it are preserved so the decision can be examined later. Reviewability supports reproducibility; reproducibility is what makes a decision defensible rather than an opinion. Full coverage across every decision surface is architecture-backed and in progress; not every decision surface is field-proven yet.
GoSentrix escalates. A decision that requests stop without sufficient evidence to support it is escalated rather than silently allowed. The escalation reason is recorded. The required evidence must be supplied before enforcement authority can be claimed.
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 customer-defined approval chains. Each override is recorded with the evidence, policy version, and authorization that produced it. AI agents cannot grant overrides.
The operator action is recorded as evidence input to the next verification round, not as terminal closure. GoSentrix re-evaluates the original evidence against the new artifact and compares outcomes. If the evidence still shows the original behavior, the fix did not work — regardless of what the ticket says. A closed ticket is not evidence that risk was removed.
Validated autofix means an AI-generated or automated fix is not considered complete until independent evidence confirms the risk was removed. Compilation, test pass, or ticket closure are not validation. Verification requires corroboration against the original finding, with risk absent, risk present, or indeterminate as the only outcomes.
GoSentrix operates across code, merge, release, and runtime surfaces. At each surface it does the same four things: ingests signals, promotes evidence under doctrine, evaluates evidence against the active policy version, and emits an explicit outcome that can be reviewed later.
Yes. At every pull request, GoSentrix takes scanner findings, AI-agent claims, and prior-decision context as inputs, qualifies the evidence under doctrine, evaluates it against the active policy version, and produces a merge readiness decision — proceed, stop, escalate, or require authorization — with a preserved decision record.
Yes. At release, GoSentrix aggregates per-service evidence into a workspace-scope decision with collective evidence references. The workspace decision is its own decision, not the worst per-service verdict. Supply-chain and eligibility checks run as parallel decision axes with their own gates.
Yes, within supported evidence paths. When a developer marks a finding fixed, GoSentrix re-evaluates the original evidence 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.
Runtime telemetry can be one of the evidence sources GoSentrix verifies against. Runtime signals enter as unverified claims and can corroborate findings, contribute to fix verification, and inform downgrades when expected behavior is not observed. Runtime verification as a fully governed path is a roadmap item, not a field-proven claim.
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 verification without independent non-probabilistic evidence.
GoSentrix consumes signals from SBOM tools, SCA, CI, build systems, and artifact registries as evidence inputs. It evaluates whether the evidence — such as dependency state, build provenance, and attestation — satisfies customer-defined policy for a release decision. It does not generate SBOMs or supply chain attestations.
Runtime context shows which vulnerabilities are actually exercised in production. A critical CVE in a dependency that is never loaded is different from the same CVE in a function called on every request. Runtime signals can also corroborate fixes by showing that expected safe behavior is observed.
No. AI agents are upstream sources whose signals GoSentrix verifies. GoSentrix does not compete with AI coding agents, AI review agents, or AI security agents — it determines what their outputs are allowed to support.
No. AI judgment cannot authorize enforcement alone. AI-provenance signals are capped at the detected evidence level by design. Authority requires corroboration from independent non-probabilistic evidence. The principle we apply: Evidence can be uncertain. Policy evaluation must be reproducible, and insufficient evidence must be escalated.
Because AI judgment is probabilistic. AI signals contribute to corroboration the same way scanner findings do — but they cannot terminate verification on their own. A decision that stops a release on AI confidence alone cannot be defended later if the AI was wrong.
GoSentrix does not claim to have solved AI hallucination. What it does is move AI judgment from the "authority" column to the "input" column, structurally. An AI claim that a vulnerability is safe enters as a claim, not as truth. Promotion to higher evidence levels requires corroboration from sources that are not subject to hallucination.
Agentic application security is the practice of governing security evidence produced by autonomous coding agents, AI assistants, and agentic workflows. It treats AI-generated claims as probabilistic inputs and requires independent, policy-bound verification before those claims can support a release decision.
MCP governance is the policy and control framework that determines which AI agents can invoke which Model Context Protocol tools, what evidence must be captured, and how those actions are reviewed. It ensures agent activity is explainable and bound to organizational policy.
An AI-BOM is an AI bill of materials: a structured record of the AI models, training data, prompts, agents, tools, and generated artifacts that contribute to a software system. It supports AI development lifecycle security by making AI provenance reviewable.
No. GoSentrix does not replace ASPM, scanners, SCA, SAST, CI/CD gates, ticketing systems, or runtime tools. Those systems generate and manage important signals. GoSentrix verifies whether the evidence behind a consequential software decision is sufficient under the policy the organization has chosen.
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 reproduced, and that GoSentrix escalates 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. Verification 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, review 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 review artifact.
Governed evidence states. Policy-version binding at decision time. Explicit escalation when evidence is insufficient. Decision-history architecture. Supported release-evidence workflows.
Customer review-time reduction, unsupported approval detection, verification-to-enforcement conversion, and expansion across release paths are in controlled pilot. Field-proven authority and incident-prevention evidence are not yet claimed.
Because the release-evidence verification 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.
