# Odin

> Odin is the Boltcliq identity and access platform: authentication and authorization for people, services and AI agents, with one policy decision point.

Canonical URL: https://www.boltcliq.com/products/odin
Part of: https://www.boltcliq.com/llms.txt

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.
- One: policy decision API, used by every Boltcliq product
- Short-lived: scoped credentials for machines and agents, with no shared long-lived keys
- Both names: every delegated action traces to the agent and to the person
- Open parts: built on proven open identity and authorization components, not custom cryptography
- Every person, service and agent gets an identity. Every request gets one answer.
### Overview
- 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.
### Odin in one picture
- 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.
- One identity for every person, service and agent, with a clear owner for each.
- Rules written once and applied by every product through a single decision API.
- A tamper-evident record of who was allowed to do what, ready for an auditor.
- Schematic of Odin. Illustrative, not a product screenshot.
### How it works
**Give everything an identity**
- 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.
**Write the rules once**
- 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.
**Decide at every request**
- 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.
**Delegate with a narrower scope**
- 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.
**Record and review**
- 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.
### Capabilities
**Workforce identity**
- 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.
- Single sign-on and MFA
- Directory sync and federation
- Joiner, mover and leaver lifecycle
- Most access incidents start with an account that should have been closed.
**Machine and agent identity**
- 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.
- Workload identities for services and agents
- Short-lived scoped tokens
- Named owner and purpose for each
- An agent without its own identity is a person's password in the wrong hands.
**Authorization**
- 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.
- Roles, attributes and relationships
- One decision API for every product
- Allow or deny with the reason
- Real rules are about who is related to what, not only about job titles.
**Secrets and key management**
- 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.
- Vaulting and rotation
- Brokered credentials for agents
- Customer-managed keys (design goal)
- A secret an agent cannot see is a secret a stolen prompt cannot leak.
**Delegation**
- 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.
- On-behalf-of tokens carrying both names
- Scope always narrower than the person
- Revocation that takes effect quickly
- Accountability needs a human name on every action, even when software did the work.
**Audit**
- 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.
- Authentication and decision log
- Policy change history
- Exports for regulators and examiners
- Audit is only useful if nobody, including administrators, can quietly edit it.
**Tenancy and organizations**
- 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.
- Tenants, organizations, environments, projects
- Delegated administration
- Explicit cross-boundary access
- Groups, ministries and holding companies need separation of duties as much as sharing.
**Customer identity and national ID**
- 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 sign-in
- National ID and eKYC integrations
- Workforce and machine identity come first
- Customer identity varies by country, so we will not promise it before we have partners.
### Why agents need their own identity
- 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.
- One identity per agent, with a named human owner.
- On-behalf-of tokens that carry both names.
- Scope narrower than the person, lifetime in minutes.
- Revocation that does not depend on finding every key.
### Use cases across Africa
- Banks
- 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.
- 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.
- The head of operations decides who owns each automation. Compliance decides which actions need two people. Internal audit decides what to review and when.
- Telecoms
- An operator has dealers, field agents and partner systems that need access to parts of its platforms. Access is granted by email and rarely removed. Network integrations use static keys.
- Odin limits dealer and field-agent access by territory and by relationship, such as an agent seeing only their own outlets. Service integrations receive short-lived tokens instead of static keys. Access by third parties expires unless it is renewed.
- Regional managers decide which territory each agent covers. The security team decides how long partner access may last.
- Agriculture
- A cooperative union has extension officers, field agents and finance staff who use records of thousands of farmers. Officers change areas each season, and farmers have not agreed to share their data with everyone.
- Odin grants access by relationship: an officer sees the farmers assigned to them and no others. When the assignment changes, access changes with it. Reads of sensitive records are logged, so a union can show a farmer who looked at their file.
- The union decides which roles may see financial records. Cooperative leaders decide how assignments are made each season.
- Government
- A ministry has several agencies that handle the same citizen cases. Separation of duties is required by law, but the rules are enforced by habit and by paper. Oversight bodies want to see who accessed what.
- Odin enforces ministry-level separation of duties, so one official cannot both raise and approve a payment. Cross-agency access is granted by relationship, for example a case worker to an assigned case. The audit stream gives oversight bodies a record of every access.
- Permanent secretaries decide the separation rules. Oversight bodies decide what evidence they need and how often.
### Interfaces
- OIDC and OAuth 2
- Target interface. Confirmed per release.
- SAML
- For enterprise single sign-on. To be confirmed.
- SCIM and directory sync
- Target interface.
- Policy decision API
- One call for every product: allow or deny with the reason.
- Token exchange
- For delegation, on behalf of a named person.
- Secrets API
- Audit export
- File formats to be confirmed with regulators.
- SDKs
- National ID and eKYC providers
- Examples under consideration: NIN, Smile ID, MOSIP-based systems.
- Customer identity
- 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.
### Security and sovereignty
**Single decision point**
- Identity and policy decisions are made only in Odin. Other products ask, and cannot quietly overrule the answer.
**No raw secrets for agents**
- Credentials are brokered for each call and expire. An agent cannot leak a key it never held.
**Tamper-evident audit**
- The audit stream is append-only and designed so that changes can be detected, including changes by administrators.
**Inside your boundary**
- Odin is deployed on Argus in your boundary. Keys can be customer-managed. Residency options follow Argus.
### What Odin does and does not do
- Authenticate people, services and agents.
- Authorize every request through one decision API.
- Broker secrets and issue short-lived scoped tokens.
- Delegate from a person to an agent with a narrower scope.
- Keep a tamper-evident audit of decisions and changes.
- Store business data. Zeus and Argus do.
- Set agent-specific governance policy. It is written in Monolith and evaluated by Odin.
- Observe or analyse behaviour. Cyclopes does.
- Handle customer logins or national ID checks at first.
- Write its own cryptography or protocols. It composes proven open components.
### Questions
- Do you write your own authentication code?
- No. The design is to compose proven open components, such as an OIDC and OAuth provider and a relationship-based authorization engine. We differentiate on agent identity, delegation, African identity integrations and ease of operation.
- How do AI agents get permissions?
- Each agent has its own identity, a named owner and a scope narrower than the person it acts for. Credentials are short-lived and brokered. What an agent may know and do is written as Monolith policy and evaluated through Odin.
- Can we connect our existing directory or single sign-on?
- Directory sync and federation are core to workforce identity. The exact list of directories and protocols will be confirmed per design partner and per release. Interfaces listed on this page are targets.
- Does Odin handle our customers' logins and eKYC?
- Not at first. Workforce and machine identity come first. Customer identity and national ID integration are a later module, and the decision is still open. We will update this page when it is settled.
- Who can see the audit log?
- Whoever the policy allows. Odin also controls who may view the logs in Cyclopes, so a sensitive record does not become visible because it appears in an observability tool.