Vulnerability disclosure

This policy describes how to report a security issue affecting the aaes.ai website, lawfully obtained AAES Infer software, or client-operated AAES Operate or Govern that you deploy yourself. Public Infer access is not open.

The aaes.ai website. Good-faith research against the public website is in scope when it is limited to what is needed to demonstrate a vulnerability, does not degrade the site for others, does not access, alter, or exfiltrate another person's data, and does not introduce malware. Flooding, credential stuffing, and spam against the contact form are not good-faith research. Testing aaes.ai is otherwise out of scope except as this policy allows.

Client-operated AAES software. This covers AAES Operate and AAES Govern software you obtained lawfully and deploy yourself, or that a client has authorized you to test. For AAES Govern, reports that show a way to defeat a claimed control are in scope. Examples include obtaining, widening, or replaying a credential grant beyond policy; altering, omitting, or reordering a sealed record without detection; completing an irreversible action without the required approval by an authorized person; or leaking secrets into logs, pages, or error messages.

AAES Operate and its open-source components. AAES Operate is built on open-source components; the component inventory is provided in the evaluation package. Security issues in AAES Operate as AAES ships it, including issues in those components, are in scope. AAES handles vulnerability reports for the software it supplies, including its open-source components. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include AAES Govern's controls, so the absence of those controls in AAES Operate is not a finding.

AAES Infer. Reports about lawfully obtained Infer code, a local test instance or an explicitly authorized private evaluation are in scope. Examples include crossing company or project boundaries, bypassing jurisdiction or offer qualification, unauthorized billing changes, or disclosure of credentials or prompt/output content. Test with synthetic data and payment test mode. This policy does not authorize probing a private or hosted Infer endpoint, provider account or payment service without the relevant operator’s permission.

AAES-hosted client deployments require explicit authorization from AAES and the relevant client before testing. Do not scan for client deployments. Do not attempt to obtain or test a private GitHub repository you have not been given. Do not test another organization's deployment without that client's authorization.

Known product limits are not treated as new findings. Observation records activity but cannot block it. Public Infer access is not open. Operate and Govern can be client-operated or hosted by AAES.

An operator may explicitly opt into plain HTTP for the AAES Govern daemon's API and console listeners with -allow-insecure-http or AAES_ALLOW_INSECURE_HTTP=1, including on loopback. Without that opt-in, those listeners require TLS.

Do not post vulnerability details in a public issue or public forum. Email us with the subject line Security.

To

security@aaes.ai

Subject

Security

Include the affected system (the website, or the software version or commit if you know it), the property you believe is defeated, and the smallest reproduction you can manage. Remove credentials, private keys, and other people's data from the first message.

To encrypt a report, use our PGP public key for security@aaes.ai, fingerprint C53E B92A 9845 D5DF 0AB6 0434 B795 161C AEA6 B5B1. Check the fingerprint before you rely on the key. If you cannot use PGP, send an initial report without sensitive details and we will agree a secure channel.

Acknowledgment

Within five business days. If you hear nothing after seven business days, send again in the same thread. We will follow up in the same thread.

Assessment

A substantive assessment within fifteen business days: whether the report reproduces, which claimed property it defeats, and whether it is in scope. We may ask for more information to reproduce the issue. If we dispute severity, we will say why in writing.

Fix or accepted risk

A confirmed defect is either fixed or recorded as an accepted risk, with the reason. You will be told which. For a planned fix, we ask to coordinate public discussion after the fix is available, subject to the disclosure periods below. For an accepted risk, we will explain the remaining exposure and propose a disclosure date; acceptance does not require the reporter to withhold the finding indefinitely.

Coordinated disclosure

We ask for 90 days from acknowledgment before public discussion. We will credit you unless you ask us not to. If we need longer, we will say so and say why. If you have heard nothing substantive for 60 days after acknowledgment, you may disclose.

These response commitments are not a service-level agreement (SLA) for product availability.

If you act in good faith, stay within the scopes named above, do only what is needed to demonstrate the issue, do not access, alter, or exfiltrate another party's data, and do not degrade a service others use, then your research is authorized under this policy. We will not pursue or support legal action against you for that research.

Questions about this policy: security@aaes.ai. The same contact is published as an RFC 9116 security.txt at /.well-known/security.txt.