Helm7
Start free

Let an agent sign in to test your app. Never let it hold the password.

A test account is a user in your product that an agent or a CI job can sign in as, for one environment. Helm7 creates it, keeps its credentials, and releases them only to a key with its own scope, for one run.

Read the docsStart free

Four calls. Every credential is logged.

An agent tests a checkout as a temporary user. Step through it: the agent creates the user, checks it out to sign in, asks for a 2FA code and deletes it afterwards.

  1. e2e-agent
  2. Test run
1 of 4 calls

  1. 1Make a throwaway user in the preview environment. It should be gone by tomorrow.Agent, over MCP

    test_account_create {"productId":"prd_7k2m9x4qw1nv8bz3ct6d","environment":"preview","label":"checkout-e2e","mode":"provision","expires_in":"24h"}
    {
  "id": "tac_7k2m9x4qw1nv8bz3ct6d",
  "label": "checkout-e2e",
  "status": "active",
  "password": "write-only, never returned",
  "expires_in": "24h"
}

Ids and times are made up. Secret values are hidden.

  1. checkout-e2e
  2. Audit log
  1. 09:12:04created by e2e-agentpreview, expires in 24 hours

Each checkout is recorded with the run that asked.

Why not just give it a login?

A password pasted into a prompt is in the transcript, the logs and whatever the model writes next. A shared staging user never expires and nobody knows who last used it. This is the other way round.

  • One call or one click

    Helm7 creates the user in the product’s own auth and tags it as a test user, so analytics and revenue can leave it out. Give it an expiry and it removes itself. Already have an account you test with? Register it instead.

  • Short-lived by design

    Passwords and 2FA seeds are encrypted when stored and never shown in a list. An agent can check one out over MCP, but only with a key that holds the separate use scope, and a throwaway account with an expiry limits what a leak is worth.

  • Two-factor still works

    If the product asks for a code at sign-in, Helm7 generates it on its side for that one step. The seed it comes from is never returned to anyone.

  • Every use leaves a record

    Each checkout is logged with the run that asked, and its sessions are revoked when the lease ends. Rotate a password whenever you like, or delete the account and its access goes with it.

Everywhere you already work.

Test accounts are operations like any other, so the dashboard, the API, the CLI, MCP and the SDK all do the same things and none of them can do more than another.

How each one works

  • Dashboard

    A test accounts panel on each Product. Create, register, rotate or delete.

  • REST API

    The same operations as everything else, with dry runs and idempotency keys.

  • CLI

    helm7 test-accounts, from a terminal or a CI step.

  • MCP

    Everything above, including checkout and 2FA codes, for an agent.

  • SDK

    Typed methods over the same catalogue, for tests written in code.

Questions about test accounts.

Want the detail? The documentation covers each operation.

  • Does the AI model ever see the password?

    Only if you let it. A password is write-only: no list or inspect call returns it. Checkout does, to a key with the separate use scope, and the call is logged with the run that asked. Give the account an expiry and a leaked password stops working on its own.

  • What does a test account do to my real users?

    It is created in the same auth your customers use, so the product treats it like any other user. It is tagged as a test user, which is how analytics and revenue views leave it out, and it can only be deleted through Helm7 if it carries that tag.

  • What if the sign-in needs a 2FA code?

    Store the account’s 2FA seed when you create or register it. When the product asks for a code, the agent or test code requests the current one and Helm7 returns six digits and how long they last. Helm7 does not enrol the seed anywhere.

  • Can I use an account that already exists?

    Yes. Register it with its email, its password and, if it has one, its 2FA seed. This is also how you cover a product hosted outside Helm7. Deleting a registered account removes the record here and leaves the user in your product.

  • Can it make a purchase?

    No, and it should not try. Test accounts must never pay for anything real, so a flow that reaches a live paywall should stop there.

  • Can I run it from CI without an agent?

    Yes. The CLI and the SDK call the same operations, so a pipeline can create an account, check it out for the test run and delete it afterwards.