How bleib works.

Your agent knows where to ask

Connect a compatible agent to your bleib wallet. Each goal starts a permission request. As the agent works, access to information, disclosure, spending, and other actions must stay within the authority you granted.

• Context: the identity, relationships, and preferences you approve.
• Authority: who may access, disclose, or act; for which purpose; within which limits; and until when.
• Sources: references to the systems that hold authoritative records.

The wallet does not need an AI to interpret your life. The agent can reason and propose; fixed policy rules decide whether a structured request is permitted.

Your agent and theirs

Your agent can coordinate with a friend’s agent, a travel company’s agent, or another service. Each participant needs its own authority. Recognizing a person or company does not give its agent unrestricted access.

For dinner with Marek, an approved availability answer can be enough. His agent does not need your calendar entries to agree a time.

A request has a defined scope

An agent proposes the information or action it wants to use. An approved task template or your explicit decision defines the permission. Calling a request “necessary for dinner” does not make it authorized.

• The requesting agent and the intended recipient.
• The approved task or purpose.
• The specific source, fields, or action.
• Spending limits, approval conditions, expiry, and revocation.

Allow. Ask. Refuse.

A request covered by standing permission can proceed without another prompt. A request requiring a new decision comes to you. A request outside the permission is refused.

These decisions are deterministic checks of the request against your rules. They do not depend on an AI deciding that an agent sounds trustworthy.

A rogue agent can ask. It cannot grant itself access.

An agent may request your entire calendar. That request must still fail if its permission covers only a free/busy answer for a dinner plan.

The system releasing information or performing an action must verify the permission before it proceeds. It must check the agent, recipient, scope, limits, expiry, and revocation state. Agents must not receive broad source credentials that bypass this boundary.

The wallet cannot determine from an arbitrary sentence what a task truly needs. That scope comes from a previously approved task definition or a decision you authorize.

An answer can leave. The records can stay.

Your calendar, health information, photos, and banking records can stay with their trusted sources. bleib holds the map and the rules around them.

Prefer a proof or a derived answer where it is sufficient: “Free Friday evening” instead of every calendar entry. Grant temporary access to specific records only when the approved task requires it.

Once raw information has been released to a recipient, permission checks cannot guarantee its later use or recall every copy. Reducing what leaves is part of the design.

Your keys. Your context. Your authority.

The target is a self-custodied wallet: root authority held by keys you control, with portable encrypted context and permissions. Agents receive narrow capabilities; they do not receive your root keys.

The proposed blockchain registry would make control and revocation independently verifiable. It would hold minimal public state such as controller keys, commitments, and revocation references. Personal context and source records would stay off-chain.

Ownership depends on all three working together: your keys, exportable encrypted state, and an independently verifiable registry. The aim is that compatible clients can keep using your wallet without depending on bleib’s servers. The chain, recovery design, and protocol are still being evaluated.

Your agent learns. You approve what stays.

There is no need to define every permission before you start. When a new decision arises, your agent can ask. You can answer by voice or text, adding conditions in your own words.

The language model interprets and proposes. The wallet stores the approved rule and enforces it deterministically. An agent cannot widen that rule on its own.

For a broad request such as sharing health information, your agent clarifies the recipient, records, purpose, and duration before you approve the permission.

Remembering something and disclosing it are separate permissions. You can change the preference, restrict its use, or revoke access. The approved context stays yours as agents change.

Verified by code

Cryptographic signatures bind a permission to its issuer and the agent allowed to use it. Verification also applies the scope, limits, expiry, and revocation state. A record can show which authority an action used.

A handwritten signature is not involved. The permission is a verifiable capability, enforced outside the model.

Developers can read the proposed integration model.