Toqen.app

I really do not like this phrase.

Usually, it is said after something has already happened that could have been prevented. After data has already leaked. After people have already faced the consequences. After a system has already shown that the usual approach was not enough.

That is why I prefer to speak earlier.

The Incident in Lithuania

The recent data breach involving government registries in Lithuania once again shows how important access infrastructure has become. Especially when it involves government records, real estate, legal entities, and people’s trust in digital services.

I sincerely sympathize with everyone affected by this situation. Incidents like this are never just technical problems. Behind them are real people, teams, organizations, and users.

Why It Is Important to Discuss a New Approach

That is why I believe it is important to calmly and professionally discuss new approaches to security.

I am working on Toqen.app in the direction of access first authentication infrastructure designed for secure, real time authorization.

The idea is simple: access should become a separate, verifiable event. With clear context, a short lifetime, cryptographic confirmation, and minimized unnecessary data.

An Invitation to Collaborate

I am open to collaboration with teams, organizations, and specialists who care about this topic.

And even if collaboration is not needed right now, I would be glad if more people simply started exploring these ideas: authorization at action level, device bound signatures, short lived authorization requests, and real time access verification.

People can build their own systems. People can challenge my ideas. People can independently develop this direction further.

The important thing is for these approaches to appear before another incident once again proves why they are needed.

A Necessary Conversation

Security evolves through attention, dialogue, and collaboration. This conversation is necessary, and it is better to have it before the next incident forces it upon us.

Article: https://www.antonmb.com/en/blog/rethinking-access-security-after-the-lithuania-breach

I published a personal essay about writing in the age of AI:

https://www.antonmb.com/en/blog/writing-in-the-age-of-ai

The core idea is simple: for me, writing is becoming a form of research.

It starts with a raw thought, then moves through questions, doubt, criticism, rewriting, and a deeper attempt to understand what I actually think.

AI does not replace that process for me. It helps me stay in it.

It acts as a conversation partner, editor, opponent, and sometimes a mirror that makes my own thinking more visible.

This made me think about something broader: maybe one of the strongest uses of AI is not only productivity, but better thinking.

Curious how others use AI for writing.

Do you use it mainly to produce content faster, or to think more clearly?

My LinkedIn newsletter, Access-First Auth System, just passed 1,000 subscribers.

Thank you to everyone reading and following it 💖

I started it to write about access-first authentication, privacy-aware system design, and modern approaches to authentication while building Toqen.app.

Next step: more practical articles around auth flows, trust, device-based authorization, and secure access design.

https://www.linkedin.com/newsletters/access-first-auth-system-7408371035399479297/

#Authentication #CyberSecurity #Privacy #ProductEngineering #Startup

Over the past months I built Toqen.app, an access first authentication infrastructure product, independently from the ground up.

That included architecture, backend, frontend, mobile applications, infrastructure, and product design.

Building a technically complex product solo across multiple domains has been one of the most challenging and valuable experiences of my career.

While continuing to develop the project, I am also open to new opportunities, contract work, and collaboration with teams building ambitious products.

My strongest areas are:
• Product Engineering
• Full Stack Development
• Architecture
• Technical Leadership

If you are building something and need an experienced engineer, I would be glad to connect.

Portfolio / CV: https://www.antonmb.com

OpenAI recently published its view on preparing society and institutions for the transition toward superintelligence. In the technical part of that discussion, several themes stand out clearly: AI trust stack, control of agent actions, verifiable operations, post deployment safety, auditability, accountability, and governance for agentic systems.

OpenAI: Industrial Policy for the Intelligence Age

These themes point to an architectural problem that will become increasingly important as AI systems move from answering questions to performing actions.

When AI systems become agents, the security question changes.

It is no longer enough to ask only who initiated a process. Systems also need to know what action is being requested, under which conditions, for how long, with which limits, and how this action can be verified later.

This is where access control becomes a primary architectural layer.

From authentication events to action level control

Traditional authentication systems are usually designed around a subject: a user, an account, an organization, a device, or a service identity.

That model remains important.

However, agentic systems introduce a second layer of complexity. A human, an AI agent, a robot, a service, or another automated process may request access to perform a specific operation in a specific context.

In this environment, the most important security object is often the action itself.

• An agent wants to call an API.

• A robot wants to execute a physical operation.

• A system wants to delegate a task to another system.

• A human wants to authorize an AI agent to act within defined limits.

• A workflow needs temporary access to data, tools, or infrastructure.

Each of these cases requires more than a static permission. It requires a controlled access event with a clear scope, lifetime, verification mechanism, and audit trail.

Why this matters for AI trust stack

OpenAI’s AI trust stack direction describes the need for systems that help people trust and verify AI systems, the content they produce, and the actions they take. This includes verifiable signatures, provenance, privacy preserving logs, investigation mechanisms, delegation, monitoring, and escalation.

These are access layer problems.

A practical trust stack for agentic systems needs to answer several questions at runtime:

• Who or what requested the action?

• Which entity was allowed to perform it?

• Was the authorization valid at execution time?

• Was the action inside the allowed scope?

• Can the event be verified later?

• Can access be limited, expired, or revoked?

• Can this be done with minimal data collection?

This is the space where access first infrastructure becomes relevant.

Access first as an architectural model

The access first model treats access as a first class object.

In this model, an authorization event can be represented as a cryptographically verifiable object with defined parameters:

• entity identifier

• requested action

• scope

• context

• expiration

• usage limits

• signature

• audit metadata

• revocation status

The system does not need to turn every interaction into a broad identity profile. It can focus on the specific right to perform a specific operation under specific conditions.

This is especially important for AI agents and robotic systems, where the core question is practical and operational:

What is this entity allowed to do right now?

Where Toqen.app fits

Toqen.app is being developed as access first authentication infrastructure.

The current core is focused on issuing and controlling access. The same direction can be extended toward agentic systems, where access events become the main control unit for interactions between humans, agents, services, and automated systems.

The relevant parts of the Toqen approach are:

• Access is treated as a separate verifiable event.

• Access can be bound to an entity, such as a human, agent, system, service, or robot, through a key based model.

• An operation can be confirmed, limited, expired, or revoked at execution time.

• Audit data can be minimal and focused on verifiable events.

• The model can support human to agent and agent to agent interactions.

This does not require replacing existing identity systems. It can work as an additional access layer for action level authorization.

Distributed agents and blockchain based coordination

Some agentic systems will operate across independent participants.

This is especially relevant for industrial automation, robotics, logistics, manufacturing, and multi organization AI workflows. In such environments, multiple systems may need to agree on access events without relying on a single internal database controlled by one party.

A blockchain or distributed ledger layer can be useful in specific cases as a synchronization and immutability mechanism for access events.

In this model:

• Toqen manages access issuance and action level control.

• A distributed ledger records selected access events, state changes, or revocation signals.

• Independent participants can verify the state of permissions.

• The system can preserve a shared record without exposing unnecessary private data.

This is not required for every scenario. For many applications, a conventional audit log is enough. But in distributed industrial and multi party environments, blockchain can provide a useful coordination layer.

The practical direction

The practical engineering direction is clear:

• AI agents need controlled access to tools, data, APIs, and physical systems.

• Those permissions need to be scoped, temporary, verifiable, and revocable.

• Critical operations need runtime control.

• Post deployment safety requires action level visibility.

• Audit and accountability require verifiable chains of events.

• Access first infrastructure is one possible way to build this layer.

The main shift is simple:

As AI systems become more autonomous, access control must move closer to the action itself.

Conclusion

OpenAI’s discussion of superintelligence highlights a broader infrastructure need: systems that can verify, limit, monitor, and audit the actions of AI agents after deployment.

This is a concrete engineering problem.

Access first infrastructure addresses that problem by treating access as a controllable, verifiable, time bound, and action level object.

For AI agents, robotic systems, and distributed workflows, this model can become an important part of the future AI trust stack.

Toqen.app is being built in this direction: access first authentication infrastructure for systems where secure, real time authorization becomes a core part of the architecture.

Sources

OpenAI: Industrial Policy for the Intelligence Age

OpenAI: Accelerating the Next Phase of AI

In the first part, I wrote about a simple shift: in the AI era, knowledge is no longer the main scarce resource.

When information becomes available almost instantly, the real value moves toward problem solving, judgment, responsibility, and trust.

This second part is about a broader idea I have been thinking about: a global trusted-contact network for finding people, specialists, and companies through real trust paths.

Not just who is visible online, but who can actually be trusted in a specific context.

The Problem with Finding People Today

Finding the right person has become easier on the surface and harder in practice.

We have search engines, professional networks, social platforms, marketplaces, communities, chats, and recommendation feeds. It seems like everyone is reachable.

But when the decision really matters, visibility is not enough.

• who can be trusted as a specialist;

• who is reliable as a partner;

• who can be safely introduced to someone;

• who has real experience in a specific context;

• who should receive access, attention, money, or responsibility.

These questions are rarely answered by public profiles alone.

Public Signals Are Not Enough

The internet mostly evaluates people through public signals.

• followers;

• likes;

• reviews;

• ratings;

• badges;

• comments;

• public recommendations.

These signals can be useful, but they are too shallow for many important decisions.

Reviews can be manipulated. Ratings often miss context. Social profiles show packaging more than real interaction history. Public recommendations may reflect politeness, marketing, or social pressure.

Real trust usually lives somewhere else.

In private conversations, personal networks, previous work, shared experience, and quiet recommendations.

Real Recommendations Are Fragmented

The strongest recommendations are often not public.

They are scattered across private chats, calls, introductions, small communities, old projects, and personal memory.

When someone needs a reliable specialist, investor, founder, lawyer, designer, developer, consultant, or local contact, the process usually starts with a simple message.

Do you know someone reliable for this?

This works, but it works slowly, randomly, and only inside the networks that are immediately visible to us.

A lot of valuable trust already exists. It is just not structured.

A Global Trusted-Contact Network

The idea is a global trusted-contact network for finding people, specialists, and companies through private trust paths.

A person could add a rough location, areas of expertise, short profile information, and the kinds of contexts where they are open to interaction.

Other people could create or remove private trust connections with that person in specific contexts.

• I trust this person as a frontend engineer;

• I can recommend this person as a designer;

• I know this person as a reliable local contact;

• I can confirm this person’s experience with fundraising;

• I would route a security-related request through this person.

The result is not a public popularity score. It is a private network of contextual trust.

Private Trust Paths

The most important part of this idea is not the profile. It is the path.

When someone needs to reach a specialist, partner, investor, company, or local contact, the system would not only show public search results. It would help route the request through a private chain of trusted people.

The full chain would not be exposed.

• each person in the path can approve the request;

• each person can stop the request;

• the requester does not see the full chain;

• if the request stops, the requester does not see where it stopped;

• the target person receives only the request that passed through the trusted path.

This keeps the process human, private, and respectful.

A Simple Example

Imagine I need a reliable tax specialist in another country.

I can search online and find dozens of profiles. Some have reviews. Some have polished websites. Some have strong public content.

But the real question is different.

Who can confirm that this person is reliable for my specific situation?

In a trusted-contact network, I could see that there is a private trust path to a specialist.

Maybe I do not know the specialist directly. But someone I trust knows someone who worked with them. The system can route the request step by step without revealing the entire network.

If people along the path approve the request, the contact can happen. If someone decides it is not appropriate, the request simply stops.

Why the Network Must Be Private

A trust network becomes dangerous if it turns into a public map of personal relationships.

Public relationship graphs can create pressure, manipulation, unwanted exposure, social debt, and uncomfortable expectations.

That is why privacy is not an extra feature. It is part of the core design.

• the full chain should not be visible;

• private connections should remain private;

• people should be able to stop requests quietly;

• rejections should not become public signals;

• the system should reveal only what is needed for the next step.

The goal is to make discovery more honest and safer, not more socially aggressive.

Controlled Disclosure

The network should work through controlled disclosure.

A person should not need to reveal their full network, full history, full identity, or every reason behind a decision.

The system should provide only the minimum necessary signal for a specific action.

• there is a trusted path;

• the request can be passed forward;

• the context is relevant;

• the person is reachable through trusted connections;

• the request was accepted or stopped.

This is the same principle that I see as important in access systems: disclose only what is necessary for the action being performed.

This Is Not a Rating System

A global trusted-contact network should not reduce people to universal scores.

Trust is too contextual for that.

Someone may be excellent in one role and unsuitable for another. Reliable in one context and unknown in another. Strong in one country, industry, or type of work, and still unverified elsewhere.

The system should not answer the question “Is this person good?”

It should help answer: who can confirm this person for this specific request?

Where This Could Be Useful

This kind of network could be useful in many areas where trust matters more than visibility.

• hiring specialists;

• finding contractors;

• international relocation;

• local services;

• investment and fundraising;

• B2B partnerships;

• legal, tax, and financial introductions;

• professional communities;

• founder and investor discovery;

• private clubs and expert groups;

• human-to-agent and agent-to-agent access flows.

In each of these areas, the problem is not only finding someone. The harder problem is understanding whether interaction is appropriate and safe.

How This Connects to Toqen.app

I am building Toqen.app as access-first authentication infrastructure designed for secure, real-time authorization.

Toqen.app solves a specific access problem: how to authorize a person quickly, securely, and with the minimum necessary amount of data.

A user opens a website, scans a QR code in the mobile app, confirms the request, and the service receives a verifiable authorization event.

The trusted-contact network is a broader idea, but it follows a similar principle.

For a specific action, the system should ask for and reveal only what is truly necessary.

Access and trust are different problems, but they are connected by the same direction: more precise digital interactions with less unnecessary exposure.

The Global Network

The global network I imagine is not a public social graph and not a popularity contest.

It is a private infrastructure layer for routing trust: from one person to another, from one company to another, from one context to another.

The internet has already made people searchable.

The next step is making trusted interaction easier, safer, and more precise.

That is the direction I see behind The Age of Trust.

In this article, I briefly explain why Toqen.app is built around an access-first authentication infrastructure.

1. Where fast access matters

There are scenarios where filling out forms gets in the way:

• one-time website visits

• Smart TVs

• events and webinars

• admin panels and systems where ownership must be confirmed frequently

• systems where services, agents, or bots interact with each other

In these cases, email and passwords slow things down and increase risk.

Toqen.app provides access instantly through confirmation, without entering unnecessary data.

2. Access without unnecessary data

Instead of creating and managing accounts:

• open the website

• scan a QR code

• confirm access

Access is confirmed at the moment of request, not stored in advance.

It does not matter where you are or what device you use everything happens in just a few steps.

3. Access control at the moment of use

With Toqen.app, every access can be:

• confirmed

• restricted

• revoked

This gives control not only at login, but during actual usage.

4. Simple and predictable security

Most authentication issues come from human error:

• forgotten passwords

• password reuse

• phishing

• input mistakes

With Toqen.app:

• no passwords to enter

• no unnecessary steps

• every access is confirmed on your device

• device-bound cryptographic keys are used

This reduces mistakes and makes the process predictable.

Even in stressful situations, there is only one action confirm access.

It follows modern approaches similar to WebAuth, with a more straightforward user experience.

5. Less data, lower risk

Traditional systems store:

• emails

• passwords

• tokens

With Toqen.app:

• only data required for access is used

• no unnecessary personal information is stored

• each access request is single-use

This reduces the impact of mistakes and data leaks.

6. Simple and fast integration

For developers, speed of integration matters as much as security.

Toqen.app:

• does not require complex setup

• does not require identity-centric user profiles

• allows collecting data required by business logic

• integrates as an access layer on top of existing systems

This makes it possible to introduce secure access without redesigning the architecture.

Summary

Toqen.app is an approach where:

• access is confirmed in real time

• unnecessary data is not required

• users stay in control

• the system remains simple and clear

You do not remember access you confirm it when you need it.

P.S.

The app is available on the App Store. Closed testing on Google Play is ongoing message me if you want to try it.

The client app is open source, so you can review how access confirmation works and what data is actually used: https://github.com/toqenapp/mobile-react-native

Friend: "So, what’s this Toqen.app thing anyway? Just another password manager? I have everything saved in my browser, I’m good."

Me: "That’s the thing - it’s not. Browsers remember your passwords. Toqen.app makes them unnecessary."

Friend: "What do you mean 'unnecessary'? How am I supposed to log in? Magic?"

Me: "Think of it this way: a standard login is like a door with a cheap lock. Anyone with a copy of the key-your password-can walk right in. Toqen.app turns your smartphone into a universal digital key. You don’t have to type anything. You just walk up to the 'door' (open the website), scan a QR code, and your phone tells the site: 'Everything’s good, this is the owner, let him in.'"

Friend: "Wait, so I don’t have to remember anything? That sounds like a security nightmare. Okay, what if I’m sitting in a cafe and someone else tries to log in using my name from the other side of the world?"

Me: "That’s the main 'wow' effect. An attacker gets nowhere because there are no reusable credentials on the server. Unlike a password, which can be stolen and used again, the server only holds your public key. To log in, your phone creates a unique device signature for that specific moment. The server only verifies the signature - it never sees or stores your actual 'secret.' Even if someone intercepted the data, they couldn't use it to log in later. Your 'master key' stays physically on your phone and nowhere else."

Friend: "Right, but what if I lose my phone? Or worse, what if it gets stolen?"

Me: "That’s the key part. It’s like the keys to a modern car: no one else can even start the 'engine' without your specific biometrics. If you lose it, you restore access via a backup. It’s stored in an encrypted format that is mathematically impractical to crack without your master key. Meanwhile, your lost device remains useless to an intruder because it's protected by multiple layers of hardware-level security."

Friend: "So... it’s basically like FaceID for the entire internet?"

Me: "Exactly. It makes your digital life seamless. You move through websites like you’re walking through your own home, where all the doors open automatically as you approach. No stress, just access."

I just open-sourced the mobile client of Toqen.app.

One thing I wanted to make very clear — the app does not collect personal or sensitive user data (no email, phone number, location, etc.).
Only device-bound identifiers and cryptographic keys required for authorization.

You can verify this directly in the code:
https://github.com/toqenapp/mobile-react-native

This is also the part of the system where access actually gets confirmed:

• user decision

• device signature

• real-time verification

I am sharing it because I realized something while building this:

The more you talk about security, the harder it is for people to trust you - unless they can actually see how things work.

So this is my attempt to make that layer transparent.

Product access:

• iOS (App Store): search for “toqen.app”

• Android (closed testing): https://forms.gle/f9FcbHyHJiajmFWV7

I am still figuring a lot of things out, so I would really appreciate any feedback or critique.

Building continues.

Over the past few days, early feedback on the Toqen mobile app has been coming in.

One pattern stood out immediately.

People hesitate to install it.

Even those who understand the idea.
Even those who know the background.

What is happening?

The moment the product is described, it gets classified as:

• a security tool

• an authentication system

• something that controls access

And that classification alone creates friction.

The default reaction becomes:

“I am not sure I want to install this.”

The unexpected part

Toqen was designed around strict constraints:

• minimal data involvement

• device-generated cryptographic keys

• no central storage of sensitive elements

• short-lived, challenge-based authentication

From an engineering perspective, this reduces risk.

From a user perspective, it does not automatically increase trust.

Meanwhile

People regularly install apps that:

• request access to contacts

• track behavior

• collect large amounts of personal data

And do so without hesitation.

Because those apps are perceived as:

• social

• entertainment

• familiar

The insight

Trust is not created by architecture.

It is created by perception.

Even a system designed to reduce data exposure can be treated as more risky than one that collects significantly more data.

What this changed

This feedback forced a rethink.

If trust is not visible, it does not exist.

So the focus shifts from:

“build a secure system”

to:

“build a system that can be understood and verified”

The decision

The mobile app is being prepared for open source release.

Not as a marketing step.

But as a way to make the system:

• inspectable

• transparent

• understandable

Current state

• Google Play testing is active (access available on request)

• the release version is live in the App Store

Search: toqen.app

Takeaway

If a product operates in a “security” category, it starts with a trust deficit.

That deficit cannot be solved by better architecture alone.

It requires:

• clarity

• transparency

• verifiability

This was not obvious before launch.

Now it is.