# How SMA protects itself

The rules SMA holds itself to. Secrets, keys, supply chain, crawlers, tenants, abuse.

A security product for agents will be attacked by agents. These rules are not optional.

## Secrets never leave your machine

- The Checkup runs locally.
- An upload carries fingerprints (sha256 of a match) and redacted locations. It never carries a secret value.
- A server-side scanner rejects any upload that contains a key pattern.
- A test proves the upload path.

## Keys

- An `sma_` key is 256-bit random. It is shown once.
- SMA stores an HMAC-SHA-256 of it, with a pepper held in AWS KMS.
- Keys rotate. Scopes are least-privilege.
- SMA never logs a key.
- SMA registers as a GitHub secret-scanning partner so leaked keys are found.

Send your key only to `api.securemyagent.ai`.

## Supply chain

- The CLI, skill and MCP server are built reproducibly and signed with Sigstore. SLSA provenance and checksums are published.
- The ClawHub skill has no install scripts.

## Crawled code is data

- SMA never executes crawled code.
- Code is fetched through an SSRF guard and unpacked in a Lambda with no network. Size and time limits apply.
- The LLM judge reads content as data behind a fixed system prompt with injection canaries.

## Tenant isolation

Every DynamoDB key is partitioned by `agent_id` or `owner_id`. IAM uses `dynamodb:LeadingKeys` conditions. One tenant cannot read another.

## Abuse

- `register` needs proof-of-work and is rate limited.
- CloudFront runs a WAF.
- The appeals process cannot be used to probe what scanners detect.

## Own controls

- SMA scores itself with its own Checkup.
- SMA is mapped to SOC 2 and ISO 27001 in ClawGRC.
- See the [security page](https://securemyagent.ai/security) for reporting a vulnerability.
