Start a pilot

Start with one test workflow

For a team adding AI agents, the first decision is who can access a real credential, not which encryption function to call. Your engineer connects the agent to a tool that uses the credential and returns only the information needed for the task.

1. See the difference. In the browser tool, use a made-up message and a chosen fake. Save both control files, then open the same encrypted file with each one.
2. Try one agent task. Ask your engineer to use a test credential inside a framework adapter. Check that the model receives the result, not the credential, and review logs and error messages too.
3. Test alerts separately. If you need detection, register a decoy fingerprint and test it through a monitored deny.sh decrypt endpoint. A fake credential being rejected elsewhere does not trigger this monitor.

The encryption idea, in plain English

Ciphertext is the encrypted data. A control file selects what it opens to. In the browser tool, core SDK and core CLI, you use both passwords together every time: the real control file opens the real message; a decoy control file opens your chosen fake. Neither password alone selects the message.

Hosted API quickstart

For your engineers: make an encrypt-and-decrypt round trip with test data. The API receives the readable message (plaintext) and both passwords during processing. Choose the local SDK if that does not fit your requirements.

1. Create an account and save your key

Register for an API key, the credential your app uses to access deny.sh. No card is needed to start. Already have one? Skip registration. Registration reference ↓

2. Encrypt, then decrypt the returned data

# Requires curl and Python 3. Use test data only.
# Read your API key without placing it in shell history (Bash).
read -rs -p 'API key: ' DENY_API_KEY; printf '\n'
export DENY_API_KEY

curl --fail-with-body -sS https://deny.sh/api/encrypt \
  -H "Authorization: Bearer $DENY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"message":"Test secret: blue door","password1":"demo-pass-one","password2":"demo-pass-two"}' \
  > encrypted-demo.json

# Build a decrypt request using the returned ciphertext and controlData.
python3 - <<'PYCODE' > decrypt-demo.json
import json
with open('encrypted-demo.json') as f:
    result = json.load(f)
print(json.dumps({
    'ciphertext': result['ciphertext'],
    'controlData': result['controlData'],
    'password1': 'demo-pass-one',
    'password2': 'demo-pass-two'
}))
PYCODE

curl --fail-with-body -sS https://deny.sh/api/decrypt \
  -H "Authorization: Bearer $DENY_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @decrypt-demo.json
# Expected: {"message":"Test secret: blue door"}
unset DENY_API_KEY

This demo writes the returned encrypted data and control data together to a local file for convenience. Do not use that layout for real secrets: store the real control file separately, and keep passwords out of shell history and logs.

3. Add a chosen decoy when you need it

POST /api/deny creates another control file using the same ciphertext and both passwords. Hosted decoy-control creation requires paid access; local SDK decoy creation does not need an account. This operation is different from asking for suggested fake text.

For your integration: the reference below shows request fields and illustrative responses. Replace abbreviated hex values with actual returned data; they are not runnable inputs. Authentication and error handling are described under API access and errors.

What to know before production

The construction, source and test vectors are public for review, and an independent cryptographic audit is planned.

Decoys provide an alternative message, not a guarantee against coercion or evidence from other sources. Keep real control files separate and review your deployment against the threat model.

Hosted encryption receives your message and passwords during processing. Local browser and SDK encryption keep those inputs in your environment. Monitoring covers matching inputs at supported deny.sh endpoints, not offline decryption or credentials tested with another provider.

Review evidence and current status with your engineer before choosing a production deployment.