> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentvault.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reporting a vulnerability

> How to report a security issue in Agent Vault, what is in scope, how to test responsibly and what to expect after you report.

If you believe you have found a security issue in Agent Vault, report it
privately using the process on this page. We review every report.

## How to report

Email **[team@self.xyz](mailto:team@self.xyz)**. The same contact is published at
`https://agentvault.io/.well-known/security.txt`.

Please do not open a public GitHub issue for a security problem, and do not
disclose it publicly until we have had the opportunity to respond.

### What to include

<Steps>
  <Step title="What you found">
    One or two sentences describing the issue.
  </Step>

  <Step title="How to reproduce it">
    Concrete steps: a request, a sequence of tool calls or a minimal script, with
    the time you observed it.
  </Step>

  <Step title="The impact">
    What an attacker gains, stated plainly. This determines severity.
  </Step>

  <Step title="Anything you know about a fix">
    Optional, and always welcome.
  </Step>
</Steps>

<Warning>
  Do not include real card numbers, CVVs or passwords in a report. If a
  reproduction needs card data, use a test card and say so.
</Warning>

## Scope

### In scope

Any issue that breaks a property Agent Vault states in its
[security documentation](/security/model):

<CardGroup cols={2}>
  <Card title="A real value reaching the agent" icon="eye">
    Any path by which an agent can read a substituted card number, CVV, password,
    authenticator secret or code.
  </Card>

  <Card title="A credential resolving off-site" icon="link-slash">
    Any way to make a login token resolve on a host it is not registered for, or
    a card token resolve against its agent card rules.
  </Card>

  <Card title="Crossing accounts" icon="users">
    Any way for one account's key or session to resolve another account's
    resource.
  </Card>

  <Card title="Bypassing a spending control" icon="gauge">
    Spending past a cap, a merchant rule or an approval threshold.
  </Card>

  <Card title="Escaping key scope" icon="key">
    A scoped key resolving a resource outside its scope.
  </Card>

  <Card title="Values in records" icon="file-lock">
    A substituted value appearing in a session event, a receipt, a log or an
    analytics payload.
  </Card>

  <Card title="Instructions in data we serve" icon="comment-slash">
    Text in a checkout recipe, or any other data served to agents, that
    instructs the reading agent.
  </Card>

  <Card title="Prompt link misuse" icon="link">
    An approval, CVV or challenge link that works when it should not, for example
    after it expired or after account deletion.
  </Card>
</CardGroup>

### Where you may test

| You may test | Notes |
| - | - |
| `https://agentvault.io` | The landing page |
| `https://app.agentvault.io` | The dashboard, the practice checkout and the package downloads |
| `https://api.agentvault.io` | The HTTP API, as an application. The platform beneath it belongs to our backend provider |
| `https://mcp.agentvault.io` | The hosted MCP server |
| `wss://proxy.agentvault.io/v1` | The proxy, through a session your own API key opened |
| `https://docs.agentvault.io` | This site |
| The `@agentvault/playwright` and `@agentvault/mcp` packages | As installed from `https://app.agentvault.io` |
| The checkout recipe registry | As served by the API and the MCP server |

Use your own account, a test card and the practice checkout at
`https://app.agentvault.io/demo-checkout` wherever you can. A self-hosted
deployment is its owner's to authorize, not ours.

Not in scope, and not something we can authorize:

* Any merchant website, including through an Agent Vault session. You would be
  testing a system we do not own.
* The third-party providers Agent Vault is built on: the card vault, sign-in,
  hosting, billing and email providers. Report an issue in one of them to that
  provider.
* Social engineering, physical access and denial of service.

### Out of scope

The following are documented design decisions rather than defects.

| Not a vulnerability | Where it is documented |
| - | - |
| The merchant receives a real card number | [Security model](/security/model). This is the product's purpose |
| A screenshot is black after a fill | [Screenshot redaction](/security/redaction) |
| A token-filled checkout stores no receipt image | [Screenshot redaction](/security/redaction#receipts-follow-a-stricter-rule) |
| A blocklist card appears in a URL-narrowed catalog | [URL locking](/security/url-locking). Its exclusions are private |
| `login_blocked` and `merchant_blocked` do not say which rule applied | [URL locking](/security/url-locking#refusals). A distinguishable refusal would reveal configuration |
| A revoked key returns `invalid_api_key` rather than a distinct code | [API keys](/dashboard/api-keys). The endpoint does not reveal whether a key exists |
| `too_many_pending` carries no `Retry-After` | [Agent signup](/guides/agent-signup). A retry time would reveal when the oldest request was filed |
| `hint_unresolved` does not say which condition failed | [Page hints](/guides/page-hints). Distinguishable causes would let a caller read a filled value back one probe at a time |
| An agent spending within its limits on something you did not want | [Security model](/security/model#limitations). Limits bound the damage; they do not supply judgement |
| A recorded fill whose order was never placed still counts against a cap | [Agent cards](/dashboard/agent-cards). Reserving at fill time is what keeps caps reliable |
| Attested detokenization refusing when enabled without an enclave | [Attested detokenization](/security/attested-detokenization). Failing closed is the design |

If you believe one of these decisions is wrong rather than merely deliberate, tell
us. A documented decision can still be a poor one.

## Testing responsibly

* Test only against your own account, cards and logins.
* Do not access, modify or delete data that is not yours. If you reach another
  account's data by accident, stop, and include that in your report.
* Do not run load or denial-of-service tests.
* Use test cards where possible. Where a real purchase is unavoidable, use the
  smallest amount possible: merchants are real businesses.
* Give us reasonable time to fix an issue before any public disclosure.

## Safe harbor

Security research carried out in good faith and within this policy is
authorized. For such research, SocialConnect Labs, Inc., doing business as Self
Labs, the company behind Agent Vault:

* will not bring a civil claim against you, and will not refer you to law
  enforcement, for an accidental, good-faith breach of this policy;
* treats your research as authorized under computer misuse laws, such as the
  US Computer Fraud and Abuse Act, and will not bring a claim under
  anti-circumvention laws, such as the DMCA, for bypassing a technical control
  as far as your research needed;
* will make it known that you acted within this policy, if a third party brings
  legal action against you for research that did.

This covers our own rights only. We cannot authorize testing of systems we do
not own, so merchant websites and our providers are not covered: see
[Where you may test](#where-you-may-test). You are still expected to comply
with the law. If you are unsure whether something is covered, ask at
[team@self.xyz](mailto:team@self.xyz) before you start.

## What to expect

| Stage | Target |
| - | - |
| Acknowledgement | Within 3 business days of your report |
| Assessment | Within 10 business days of acknowledgement: we reproduce the issue, assign a severity and tell you what happens next |
| Updates | At least every 2 weeks while the issue is open, and whenever the severity or the plan changes |
| Fix | Critical: 7 days. High: 30 days. Medium: 90 days. Low: when the area next changes. Each counted from assessment |
| Resolution | We tell you when the fix is deployed, or explain our reasoning if we conclude the behaviour is intended |
| Credit | On request, once the fix is deployed |

These are targets, not guarantees. When we miss one, we tell you why and give
you a new date.

## Rewards

We do not run a bug bounty program and do not pay for reports. We credit you,
by name or handle, on request once the fix is deployed.

## Coordinated disclosure

We will agree a disclosure timeline with you. Our aim is a deployed fix before any
public write-up, and we would rather agree a date with you than ask for an
open-ended delay. If 90 days pass from your report without a deployed fix, you
may publish. Tell us the date first, so we can publish our own account alongside
yours.

## Related

<CardGroup cols={2}>
  <Card title="Security model" icon="shield" href="/security/model">
    What Agent Vault protects, and where its protection ends.
  </Card>

  <Card title="URL locking" icon="link" href="/security/url-locking">
    The anti-phishing control, and its deliberate ambiguities.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.