AI agent instructions
AI agent instructions
What you can swap
To cover every row, your secret proxy must replace stand-ins in request headers, the query string, form bodies and JSON bodies, including JSON strings written with
\u escapes. See the Evervault, VGS and custom proxy pages for what each option supports.
Each stand-in must also pass the page’s own checks before the form is sent: length, allowed characters, or a Luhn check for card numbers.
Log in with stand-ins
- Get stand-ins for the username, password and 2FA code from your provider or your own proxy.
- Start a session whose
hostslists the host that receives the login request. - Fill the stand-ins and submit the form.
- Your secret proxy swaps them on the way to that host. The site receives the real values.
2FA codes
A TOTP code changes every interval, usually 30 seconds, so a stand-in cannot map to one fixed real value. Have your secret proxy compute the code when the request passes through:- Store the TOTP seed in your proxy’s vault, next to a stable stand-in such as
tok_otp_4Lm8Rv. - The agent types that stand-in into the code field, at every login.
- On the request to the listed host, your proxy looks up the seed, computes the current code as defined in RFC 6238, with the interval, algorithm and number of digits the site set up for that account, and sends it in place of the stand-in.
- Two logins in one interval. Both get the same code, and many sites accept a code only once. After a login, wait for the next interval before the next one.
- Fields that only accept digits. If the code field only accepts six digits, the stand-in must be six digits too. A short number can also appear elsewhere in the request, so swap it only in the code field, selected by its form field name or JSON path.
- Codes sent by SMS or email. The real code arrives on a phone number or inbox you control, so your proxy cannot compute it. It would have to fetch the code at request time, which depends on your setup.
- Recovery and backup codes are fixed values. Treat them like a password.
- Provider support. Evervault’s Browser Tokens docs list passwords, recovery codes and one-time backup codes, which are stored values, and do not describe computing a value at request time. VGS’s public docs do not describe it either. For TOTP codes, use this pattern with a custom proxy, or use a Notte vault.
Limits
List the host that receives the request
Swaps only happen on requests to the hosts you list. A login page often sends the password to another host than the one in the address bar: an auth domain, a regional API host or an identity provider. A request to an unlisted host carries the stand-in unchanged, and the login fails. To find the host, open the login page in a browser with developer tools, sign in with a test account and read the host of the request that carries the password. Do the same for the 2FA step. Remember that*.example.com does not match example.com.
Your secret proxy decrypts all traffic to the listed hosts, so list only the hosts that receive secrets or send them back. A host you do not list returns its responses to the browser unchanged, so if a site shows a real value on another host, for example the account email on app.example.com, list that host too and mask its responses.
Plain HTTP
On a plain HTTP request, your secret proxy sends the real value to the site without encryption.hosts matches host names, not schemes, so a listed host the page also reaches over plain HTTP sends those requests through your proxy too. Configure your proxy to refuse plain HTTP requests or to leave their stand-ins unchanged. Evervault’s browser proxy only accepts HTTPS.
Values the page encrypts before sending
Some sites encrypt or hash the password or card number with JavaScript in the page before sending it. The request then carries a value computed from the stand-in, not the stand-in itself, so no proxy can swap it, and the site rejects the login or payment. Test each site with a stand-in before you rely on it. For these sites, a Notte vault fills the real value in the page and can work where a secret proxy cannot.Channels other than HTTP requests
This page covers values sent in HTTP requests: headers, query strings, form bodies and JSON bodies. Whether values sent in WebSocket messages are swapped depends on your proxy. Evervault’s and VGS’s public docs do not cover it, so do not rely on it without testing.Real values in responses
Many sites send account details back: the username or email on the next page, an API key shown once in a portal, a token in a JSON response. Notte does not change responses, so configure your secret proxy to replace real values with stand-ins in responses from the listed hosts. See Mask real values in responses. After a login, the site also issues its own session cookie or token. That value is real and lives in the browser, as in any session, unless your proxy replaces it with a stand-in in responses and swaps it back on requests.Secret proxy or vault
Notte vaults also fill credentials without the agent seeing them. They work differently:
Use a secret proxy when real values must never reach Notte, for example to keep Notte out of your compliance scope, or when the values already live with your tokenization provider. Use a vault when Notte holding encrypted credentials is acceptable.
You can also fill logins from 1Password or Bitwarden. In both, the real value reaches the browser, as with a Notte vault.
Next Steps
Secret Proxies
Request fields, rules and response masking
Custom proxy
Run your own secret proxy
Secret Vaults
Let Notte store and fill credentials
Cookies
Set cookies on a session