Boltcliq product / The identity and access platform
/ Trust PlaneOne answer to the question: who or what is this, and what may it do. Odin is central authentication and authorization for people, services and AI agents, including agents that act on behalf of named people.
Every person, service and agent gets an identity. Every request gets one answer.
01Trust plane
Access control in most organizations is a patchwork. Each application has its own users and roles. A leaver is removed from email but not from the finance system. Service accounts share a password that was set years ago and nobody dares to rotate. When auditors ask who could see a customer record last March, the honest answer takes weeks to assemble.
AI agents make this harder. An agent that reads files, calls tools and sends messages needs an identity and permissions like any employee, but it moves faster and can be tricked. If it borrows a person's login or holds a raw API key, one prompt injection can turn into a data breach. Odin gives every person, service and agent its own identity, and puts one policy engine in front of every request.
Odin is the only place in the Boltcliq platform where identity and policy decisions are made. Zeus, Monolith, Argus and Cyclopes do not run their own login or permission logic. They ask Odin. An agent acts on behalf of a named person with a narrower scope than that person, so every action traces back to both. Odin is designed to compose proven open components and to differentiate on agent identity, delegation and local integrations.
02
One answer to the question: who or what is this, and what may it do. Odin is central authentication and authorization for people, services and AI agents, including agents that act on behalf of named people.
03In five steps
odin
Staff sign in through single sign-on and are synced from your directory, so joiners, movers and leavers are handled in one place. Services and agents receive workload identities of their own, each with a named human owner. Nothing runs as an anonymous shared account.
Register the collections agent as a service identity owned by the head of credit.
human
Policies can be based on roles, on attributes such as branch or country, and on relationships such as a case worker being assigned to a case. They are written once and versioned. A change to a rule is reviewed like any other change.
Branch managers see only their branch's loans.
odin
Each product calls the policy decision API before it reads data or takes an action. The answer is allow or deny, with the reason. There is no second permission engine hiding inside another product to disagree with the first.
May this agent read this customer record for this purpose? No.
odin
When an agent works for a person, Odin issues a short-lived token that carries both names and a smaller scope than the person has. Secrets are brokered, so the agent never sees a raw key. The token expires on its own.
Statement agent acting for Amina, read-only, 15 minutes.
human
Every sign-in and every decision is written to a tamper-evident audit stream. Security teams review it, and exports can be prepared for regulators and examiners. Who may view the audit stream, including logs held in Cyclopes, is itself a policy.
Export all access to loan files by one team in a quarter.
04What Odin does
Single sign-on, multi-factor authentication and directory sync for your staff. Joiner, mover and leaver changes flow from your source of truth, so access follows the job. Federation with your existing directory is core to the design. The exact list of supported directories will be confirmed with each design partner.
Most access incidents start with an account that should have been closed.
Services, scheduled jobs and AI agents get workload identities with short-lived, scoped credentials. There are no shared long-lived keys. Each identity has an owner, a purpose and an expiry, and can be disabled in one action.
An agent without its own identity is a person's password in the wrong hands.
Role-based, attribute-based and relationship-based rules, evaluated through one policy decision API. You can express that a clinician may see patients they are treating, or that a branch manager sees one branch. Decisions return the reason, which makes them easy to test and to explain.
Real rules are about who is related to what, not only about job titles.
A vault for credentials and keys, with rotation and brokered access. When an agent needs to call a system, Odin supplies a credential for that call and takes it back afterwards. The agent never holds the raw secret. Customer-managed keys are a design goal for regulated customers.
A secret an agent cannot see is a secret a stolen prompt cannot leak.
An agent acts on behalf of a named person with a narrower scope and a short lifetime. Both identities are carried on every request and recorded. If the person leaves or the delegation is revoked, the agent loses access with it.
Accountability needs a human name on every action, even when software did the work.
A complete, tamper-evident record of authentications, decisions and changes to policy. It can be searched by person, agent, object and time. Exports are designed to be regulator-ready, with formats confirmed per regulator and design partner.
Audit is only useful if nobody, including administrators, can quietly edit it.
The shared definition of tenant, organization, environment and project used by every Boltcliq product. A group company, a subsidiary and a department can each have their own boundary and their own administrators. Cross-boundary access is explicit and recorded.
Groups, ministries and holding companies need separation of duties as much as sharing.
Sign-in and verification for an organization's own customers, and integration with national ID and eKYC providers, are a later module and a pending decision. Examples that are being considered include NIN in Nigeria, Smile ID and MOSIP-based systems. Nothing here is available today and the scope is not final.
Customer identity varies by country, so we will not promise it before we have partners.
05
The simplest way to give an agent access is to let it use a person's login or a shared API key. It also makes every later question hard to answer. Who deleted the file, the person or the agent? Which prompt caused it? How do you stop the agent without locking out the person?
Odin avoids this by treating an agent as a first-class identity with an owner and a scope. When it acts for a person, it carries a delegation token that names both. The scope is smaller than the person's, the lifetime is short, and the secrets it needs are supplied only for the call. If the person leaves, the delegation ends.
Free 30 minutes with an engineer.
06Sectors
Situation
A bank has tellers, branch managers and back-office staff across hundreds of branches. Staff move between branches and some leave. Back-office automation runs on shared service accounts that nobody owns.
What it does
Odin syncs staff from the directory so a move or a departure changes access the same day. Each automation gets its own identity with a named owner and a narrower scope than the person responsible. Maker-checker rules ensure that the person who prepares a payment cannot also approve it, and every decision is logged.
Human decides
The head of operations decides who owns each automation. Compliance decides which actions need two people. Internal audit decides what to review and when.
07Works with
08How you integrate
The lists describe target interfaces and are confirmed per release and per design partner. Nothing on this list is a claim that an integration with a named third party exists today.
OIDC and OAuth 2
protocol · Target interface. Confirmed per release.
SAML
protocol · For enterprise single sign-on. To be confirmed.
SCIM and directory sync
protocol · Target interface.
Policy decision API
api · One call for every product: allow or deny with the reason.
Token exchange
api · For delegation, on behalf of a named person.
Secrets API
api
Audit export
api · File formats to be confirmed with regulators.
SDKs
sdk
National ID and eKYC providers
connector · Examples under consideration: NIN, Smile ID, MOSIP-based systems.
Customer identity
channel
09Trust
Identity and policy decisions are made only in Odin. Other products ask, and cannot quietly overrule the answer.
Credentials are brokered for each call and expire. An agent cannot leak a key it never held.
The audit stream is append-only and designed so that changes can be detected, including changes by administrators.
Odin is deployed on Argus in your boundary. Keys can be customer-managed. Residency options follow Argus.
10
Does
Does not
11FAQ
Experience you can lean on
Immersed in technology and across many different verticals, so the people on your project have done this before.
Odin
Tell us the problem. An engineer, not a salesperson, answers.
One answer to the question: who or what is this, and what may it do. Odin is central authentication and authorization for people, services and AI agents, including agents that act on behalf of named people.
