BetterSign™

Why Agents Need Identity

AI agents are not just background jobs. They read repositories, open pull requests, message humans, call internal tools, manage infrastructure, and may act across many systems with different risk levels.

That makes agent identity a lifecycle problem. A team needs to know which agent acted, what capability it had at the time, which administrator authorized that capability, which key signed the action, and whether the current key is still valid.

BetterSign fits that model because a VLAD can represent an individual agent, a class of agents, a team, or an administrative authority. Current keys and permissions become verified plog state instead of scattered secrets in CI variables, Docker images, SSH files, and chat integrations.

See It In Action

Watch a short looping walkthrough: agents running without an identity layer (where an agent is at best a copied secret, or no secret at all), how BetterSign gives each one a verifiable identity and a signed delegation, revoking and provisioning an agent, and a live monitoring view where every agent is valid, unidentified, revoked, or a blocked rogue. Open the agent identity demo in a new tab.

Capability Distribution

Agent permissions can be modeled as plog state under an admin, team, class, or individual agent identity. A broad policy can apply to a class of agents, while high-risk tools can require individual agent grants.

This is useful for IAM policies, tool allowlists, repository scopes, model-access controls, deployment permissions, and environment-specific capabilities. Distribution can use ordinary infrastructure, but consumers should only apply capability state after BetterSign verification.

The admin plog becomes the history of capability creation, modification, delegation, and removal. That gives security teams a concrete timeline for why an agent could do something at the moment it acted.

Secure Agent Access

Agent servers and accounts often still need human break-glass access, debugging access, and administrative maintenance. BetterSign can distribute admin SSH keys to agent accounts through verified plog state instead of copying keys into every account by hand.

A host or account follows the relevant admin VLADs, verifies current SSH key state, and updates the managed section of authorized_keys. When an admin rotates or is removed, the agent account can converge automatically.

This gives teams remote access to agents without treating long-lived static SSH keys as permanent fixtures inside images or cloud-init scripts.

Portable Agent Teams

A team of agents can be packaged in a single Docker image for portability while keeping identity and secrets outside the immutable image. The image contains the agent runtime, tools, and expected BetterSign paths; the live identity state is resolved at deployment.

That separation matters. Rebuilding or moving the image should not require baking in new private keys, IAM documents, SSH material, or chat credentials. A deployment can start the same image in another environment and resolve the current verified state for that agent or team.

This also gives operators cleaner rollback behavior. The image version describes code and tooling. The plog describes current identity, key, and capability state.

CI/CD and Rotation

Agent keys should rotate as routine lifecycle events. BetterSign can publish current agent signing keys, encryption keys, SSH keys, and integration metadata so CI/CD systems and administrators can follow the current state without manual redistribution.

This is especially important for build agents and coding agents. The key that signs a commit today may not be the key that signs next month, but both should remain connected to the same agent identity and authorization history.

When an agent is replaced, compromised, or promoted to a stronger algorithm, followers verify the plog transition and update their accepted keys. The agent identity remains stable.

Signed Work Products

Agents can sign commits, release notes, artifacts, tool reports, and operational decisions with keys rooted in their BetterSign identity. Review systems can verify not only the signature, but also whether that key was current and authorized when the action was produced.

Messages from agents to humans should also be authenticated. Email, Telegram, chat bridges, incident updates, and approval requests can be signed and, where appropriate, encrypted to the human or team VLAD.

That reduces impersonation risk. A human should be able to distinguish an actual authorized agent message from a copied bot token, spoofed email, or stale webhook credential.

Audit and Forensics

The agent plog records key rotations and identity-local changes. The admin or team plog records capability grants, policy changes, and administrative delegation. Together they answer both who acted and why they were allowed to act.

That matters after incidents. Instead of reconstructing authority from old CI variables, chat bot settings, SSH files, and cloud consoles, investigators can replay the relevant plogs and compare signed actions to the verified state at the time.

BetterSign does not make every agent action automatically safe. It makes authority explicit, distributable, rotatable, and auditable so agent systems can be operated with the same rigor expected from human and service identities.