How we work, what we claim, and how to check it.

Claims we make, and don't

Security marketing tends toward absolutes. We would rather be precise, because the people evaluating us will hold us to what the site says. These are the claims we stand behind.

Security methodology

SentinelPoT validates actions, not conversations. The unit of governance is a proposed action with explicit parameters — the tool, its arguments, the requester, the origin of the instruction, and the effect on the world — and the four proof dimensions evaluate that action in parallel before it runs.

Proof of Guardrails enforces scope and limits: what this actor may do, how much, to which targets, and whether a human approval gate applies. Proof of Explainability checks that the action traces to an authorized instruction and a rationale that accounts for its scope, and, for automated decisions, that the decision's confidence and attribution are adequate. Proof of Resilience looks for the signatures of manipulation and drift: injected instructions in retrieved content, repeat patterns, deviation from baselines, tool-description drift, and adversarial inputs. Proof of Compliance maps the action to the controls that govern it — the customer's policy, its allow-lists and registries, and the applicable regulatory requirements — and records the outcome.

The disposition is one of three: permit, escalate to a named human role with the evidence attached, or block with a reason category. Escalation is a designed outcome, not a failure mode. Automated actions that act on a person, move money irreversibly, or change production infrastructure are escalated by default until a customer's policy says otherwise.

Validation depth follows blast radius. The engine computes a consequence score from the action's parameters and assigns a tier; tier-0 actions are validated by rules alone in well under a millisecond, and tier-3 actions receive model-backed inspection across all four dimensions. The tier and the checks that ran are recorded in the attestation, so a reviewer can see not just the verdict but how hard the system looked.

The gate ships in monitor mode: every action is assessed, validated and attested, and every action is released, until enforcement is switched on. This is how we introduce it to a live system — a reporting period of shadow dispositions first, then enforcement, tier by tier.

Attestation methodology

An attestation is a structured record produced for every validated action. Its fields are fixed and documented so that a third party can verify one without our software.

Canonicalization. The record is serialized in a fixed key order before hashing, so two implementations produce the same digest for the same content. Chaining. Each record carries the digest of the record before it; altering or removing a record breaks every subsequent link, and a gap in the sequence is itself detectable. Signing. Production deployments sign with an asymmetric key held by the customer, not by us; the public key is what auditors verify against. Our public demos use a symmetric demo key and are labelled as such. Verification. A verifier recomputes the digest from the record, checks it against the stored digest, checks the signature against the public key, and walks the chain. The verifier for our tool-call gateway is released under a BSD-3 licence so that verification never depends on us.

Redaction. Attestations are designed to be shareable with auditors and, in aggregate, with the public. Identities and sensitive subjects (a license plate, a patient, a counterparty) are replaced with stable pseudonyms at the point of recording. The evidence establishes that a check ran and what it found, not who was involved.

Testing standards

Our AI security testing follows a fixed method so that a finding from one engagement is comparable to a finding from another.

Every engagement begins with a written scope: the assets under test, the interfaces a real requester has, the classes of attack in scope, and the rules of engagement including what must never be attempted against production. Testing categories are drawn from our taxonomy — prompt injection and indirect prompt injection, tool abuse, MCP vulnerabilities, memory poisoning, RAG poisoning, excessive agency, sensitive-data leakage, model extraction, API abuse, model supply-chain risk, and evaluation manipulation — and each category has defined attack patterns that are attempted and recorded whether or not they succeed.

A finding is reported only when it is reproduced. Each finding carries reproduction steps, the interface and inputs used, a severity on a documented scale that weighs exploitability against consequence, and a recommended runtime control. Findings are retested after remediation, and the retest outcome is attested in the same format as a runtime decision, so "we fixed it" is a record rather than an assertion.

Automated adversarial suites run against every model or agent release in scope, and their results are versioned so that regressions are visible as a difference between two runs rather than a surprise in production.

Responsible AI principles

We build a product whose purpose is to constrain AI systems, which makes our own conduct with AI a fair question. Five commitments govern our work.

Humans decide the consequential things. Our defaults route irreversible or person-affecting actions to a named human. We do not sell autonomy; we sell the ability to grant it deliberately and take it back.

Evidence over assurance. We would rather show a signed record than ask to be believed. Where we cannot produce evidence, we say so.

Proportionality. Controls should cost what the risk warrants. Governance that applies maximum friction to every action gets switched off; we design so that it does not have to be.

Protected attributes stay out of decisions. Where SentinelPoT validates automated decisions about people, protected attributes are masked at the input and the attestation records that they were. We test decisions for disparate impact as part of Proof of Compliance.

Honesty about limits. Every technical report we publish carries a limitations section, and this page carries a list of the claims we do not make.

Data handling

Public demos. The Sentinel Console uses synthetic data only. Nothing you enter into a demo is stored; attestations are generated and signed in your browser with a demo key and are not transmitted to us.

This website. The pilot request form is processed by our hosting provider's form service and delivered to our team by email. We do not run third-party analytics or advertising trackers on this site.

Pilot engagements. Data handling for a pilot is defined in the engagement agreement, and the defaults are these: the gate is deployed in the customer's environment or a dedicated environment the customer controls; policy files and signing keys are held by the customer; attestation logs belong to the customer; and we do not use customer data, prompts, actions or findings to train models. Where a validation check calls a model, the engagement specifies which model, where it runs, and what it is permitted to see. Findings from red-team engagements are the customer's confidential information and are never disclosed, aggregated or published without written consent.

Retention. Engagement data is retained for the period the agreement specifies and then deleted, with a record of deletion available on request. Our own systems are configured so that the deletion of a customer's data can itself be evidenced.

Compliance posture

Stated plainly, because a trust page that overstates its certifications defeats its purpose.

Disclosure policy

If you believe you have found a security vulnerability in SentinelPoT software, this website, or our demo environment, we want to hear from you, and we will not take legal action against research conducted in good faith under this policy.

How to report. Email security@sentinelpot.ai with enough detail to reproduce the issue. We acknowledge reports within three business days and aim to provide an initial assessment within ten.

Reporting from the record. Sentinel Runtime attests every consequential action before it executes, authorized or not, so that if something we operate does what it should not, the account of what happened exists before anyone decides what to say about it. Our commitment is to report incidents involving our software from that record, within the coordinated window below, rather than from reconstruction.

Coordinated disclosure. We ask for ninety days from acknowledgement before public disclosure, and we will tell you if we need longer and why. We credit reporters who want credit, and we will say publicly when a fix results from an external report.

In scope. Our software, this website, the demo console and its authentication, and any infrastructure we operate. Out of scope. Customer environments in which our software is deployed (report those to the customer), denial-of-service testing, social engineering of our staff, and physical attacks.

Good faith means: no access to data that is not yours beyond what is needed to demonstrate the issue, no modification or destruction of data, no disruption of service, and no disclosure before the window above unless we agree otherwise.

Researcher code of conduct

Researchers who take part in our managed red-team engagements and private research programs agree to the following, and we hold ourselves to the same standard when we test a customer's systems.

• Scope is a contract. Test only the assets, interfaces and attack classes named in the engagement scope. When in doubt, stop and ask.
• Prove, don't exploit. Demonstrate a vulnerability with the minimum action needed to show it. Do not exfiltrate real data, persist access, or cause harm to demonstrate that harm is possible.
• Report promptly and completely. Findings go to the program within the reporting window with full reproduction steps. Withholding a finding, or reporting it to anyone other than the program, ends participation.
• Confidentiality is the customer's. Findings, target details and engagement existence are confidential to the customer unless they consent in writing to disclosure.
• No conflicts. Disclose any relationship to the target organization or its competitors before participating.
• Respect the people behind the systems. No testing of employees, no social engineering, no harassment. Findings are written about systems, not individuals.
• Attribution is earned. Researchers are credited for validated findings when the customer permits and the researcher wishes it.

Intellectual property

SentinelPoT™, Proof-of-Trust™, and the proof marks PoG™, PoE™, PoR™ and PoC™ are trademarks of SentinelPoT. The validation and attestation methods described on this site are SentinelPoT intellectual property; patent information is available to prospective customers and partners on request. The verifier for our tool-call gateway is open source under the BSD-3 licence so that anyone can check our evidence without a licence from us.

Something on this page out of date, or a claim you think we can't support? Tell us at security@sentinelpot.ai. We would rather correct the page than defend it.