Give every AI agent its own identity.
Agents that deploy code, query databases and call internal APIs shouldn’t run on a person’s token or a shared service account. Bastyx is designed to give each one its own identity, a named owner, a policy you can read and credentials that expire on their own.
Concept UI with sample data. The product is in development and details will change.
Agents run on borrowed credentials
Most AI agents that touch infrastructure today authenticate as someone, or something, else. That worked for scripts. It doesn’t hold up for software that decides what to do next.
- Personal tokens. An agent with a developer’s token can do everything that developer can, and the logs can’t tell them apart.
- Shared service accounts. One account for every automation, so nobody knows which agent did what.
- Secrets in the wrong places. Long-lived keys end up in prompts, config files, environment variables and traces, where a prompt injection or a leaked log can expose them.
- No off switch. Stopping a misbehaving agent means rotating secrets that other systems depend on.
Borrowed credentials vs. an agent identity
| Borrowed credentials | Bastyx agent identity | |
|---|---|---|
| Who the logs show | The person or shared account | The agent, and its owner |
| Credential lifetime | Until someone rotates it | Short-lived, issued per task |
| What it can reach | Everything the account can | Only what its policy allows |
| Sensitive actions | Run immediately | Wait for the owner’s approval |
| Leaked from a prompt or log | Works until noticed | Already expired |
| Stopping it | Rotate shared secrets | Pause or revoke in one step |
Who the logs show
- Borrowed credentials
- The person or shared account
- Bastyx agent identity
- The agent, and its owner
Credential lifetime
- Borrowed credentials
- Until someone rotates it
- Bastyx agent identity
- Short-lived, issued per task
What it can reach
- Borrowed credentials
- Everything the account can
- Bastyx agent identity
- Only what its policy allows
Sensitive actions
- Borrowed credentials
- Run immediately
- Bastyx agent identity
- Wait for the owner’s approval
Leaked from a prompt or log
- Borrowed credentials
- Works until noticed
- Bastyx agent identity
- Already expired
Stopping it
- Borrowed credentials
- Rotate shared secrets
- Bastyx agent identity
- Pause or revoke in one step
Set up an agent in five steps
Planned Describes the planned setup.
- 1
Register the agent
Name it, say what it’s for, and assign a human owner and a team. The agent now has an identity of its own, separate from everyone’s.
- 2
Scope it with a policy
List the servers, apps and APIs it may reach, the actions it may take and for how long. Policies are explicit and readable in a change review.
- 3
Connect it without a stored secret
At run time the agent proves where it’s running, using the workload identity your cloud, cluster or CI platform already issues, and gets a short-lived credential back. Nothing long-lived goes into a prompt, a config file or an environment variable.
- 4
Choose what needs approval
Mark sensitive actions, such as production changes or reading customer data. The agent waits while its owner approves with a touch of their security key.
- 5
Watch it, and stop it when needed
Every request is logged against the agent and its owner. Pause or revoke it in one step. Offboarding the owner pauses their agents too.
- OAuth 2.1
- Scoped, short-lived tokens for the APIs and MCP servers agents call.
- Workload identity
- OIDC tokens from your cloud, cluster or CI prove where an agent runs.
- FIDO2
- Owners approve sensitive actions with a touch of their security key.
Agents can’t pass as people
Giving agents their own identities solves half the problem. The other half is making sure no agent, yours or an attacker’s, can sign in as a person.
Every human sign-in to Bastyx uses FIDO2: a touch of a security key or a biometric check on the person’s own device. An agent can’t touch a key. It can’t pass a fingerprint check on hardware it doesn’t hold. And a phishing page it builds can’t get a signature for your real domain.
Recovery follows the same rule. It requires admin approval and a second registered authenticator, so an AI-generated voice on the help-desk line can’t reset anyone’s access. How FIDO2 resists phishing and AI-driven attacks.
AI agent questions
Why not just give each agent a service account?
A service account answers who, but usually not for how long, with whose approval, or who is accountable. Bastyx is designed to add a named owner, short-lived credentials, per-action policy and approvals, and one audit log that also covers your people.
Can an agent use a person’s passkey or security key?
No. FIDO2 requires the person to be present: a touch of the key or a biometric check on their own device. That’s why agents get identities of their own instead of borrowing one.
Does it work with MCP servers and agent frameworks?
We’re designing agent credentials around OAuth 2.1, the standard the Model Context Protocol builds its authorization on, so agents can get scoped, short-lived tokens for the tools they call. We’ll document supported frameworks before agent identities reach early-access teams.
Can agents SSH into servers?
That’s the intent: the same short-lived, policy-scoped access people get, recorded against the agent and its owner, with approvals for production.
What happens when an agent’s owner leaves?
Offboarding the owner pauses the agents they own, so nothing keeps running on behalf of someone who has left. Another person can take ownership before an agent is resumed.
Running agents on borrowed credentials?
Tell us which agents touch your infrastructure today. It helps decide what agent identities support first.