IAM
Who enrols the agent identity, owns its lifecycle state and preserves the link to accountable human or institutional authority?
Products & engineering
Trust, by design.
Two focused products for consequential security decisions: how identities earn trust, and how sensitive data stays under accountable custody.
Distinct products, each with its own architecture and evidence. No combined deployment is implied.
01 / Cryptographic identity
Q-Kavach
Post-quantum migration across the identity lifecycle.
Apply cryptographic choices across selected credentials, assertions, sessions and audit evidence. Evaluate one trust path from issuance through policy to the system that accepts it.
Discuss Q-Kavach Download Q-Kavach brief PDF · 2 pages- A deliberate migration path
- Explicit classical, hybrid and post-quantum profiles keep algorithm roles and downgrade decisions visible.
- Identity with an operating context
- Selected human, workload and agent paths bring scope, lifetime and lifecycle state into the trust decision.
- Evidence that can be examined
- Hash-linked records and signed checkpoints support review of selected security events.
Explore Q-Kavach architectureInteractive trust plane and delegated authority
Two architectural views
See how selected identity paths establish, assert, govern and prove before a relying system accepts trust.
View selected: Trust plane
Identity trust fabric
A migration plane for identities, not a single handshake
Principals enter through selected identity paths. Establishment, assertion, governance, and evidence remain explicit before a relying system accepts trust.
ML-KEM · supported pathsML-DSA · selected assertionsExplicit downgrade controlSigned checkpoints
Explore the architecture
Select a region in the plate or use the labels below. The complete architecture remains visible.
Mouse · touch · keyboard
Supported key-establishment paths
Establish
ML-KEM establishes shared secrets for supported exchange and envelope-protection paths.
Boundary: This is selected path coverage, not a claim that every identity transaction uses ML-KEM.
Selected: Establish
Identity & operating controlsIdentity surfaces, cryptographic roles and lifecycle
Post-quantum migration is an identity-lifecycle problem. Replacing one transport primitive leaves classical assumptions inside credentials, assertions, session controls, provisioning paths, and long-lived evidence.
Identity surfaces
- People and privileged operators
- Human and administrative paths carry explicit assurance context into policy and session decisions instead of treating a successful login as the whole trust decision.
- Workloads and agents
- Tenant-scoped enrolment and signed client assertions bring non-human actors into the identity model without reducing them to long-lived shared secrets.
- Federated assertions
- Selected issuer paths use provisioned ML-DSA profiles and protect reserved assurance claims from being silently overwritten.
- Portable credentials
- Selected verifiable-credential paths use provisioned ML-DSA signing and connect issuance events to the evidence trail.
Operating controls
- Crypto-agility
- Algorithm roles and profiles remain explicit so classical, hybrid, and post-quantum choices can coexist without an ambiguous downgrade path.
- Identity lifecycle
- Provisioning, tenant scope, session policy, revocation, and key rotation surround the cryptography with operating controls.
- Evidence continuity
- Hash-linked audit records and signed checkpoints preserve an inspectable account of selected security events and state changes.
Q-Kavach evidence & limitsFive evidence states · reviewed 28 September 2026
Dated evidence dossier
Q-Kavach evidence states
States are independent evidence categories, not steps in a maturity score. Implemented and tested do not mean deployed, certified, scaled or independently assured.
- Reviewed
- 28 September 2026
- Revision
- Public evidence review · P11.1
- Implemented
- Selected development paths model a software agent as its own identity and use signed client assertions rather than treating one shared long-lived secret as the whole identity.
- Tested
- Selected tests exercise delegation narrowing, parent binding, bounded depth, lifetime, audience, replay, lifecycle state and linked evidence with signed checkpoints on the named paths.
- Deployment-dependent
- The protected resource and its target environment must verify the exact delegated identity, scope, audience, lifetime and available lifecycle state.
- Design proposal
- Disconnected identity remains an evaluation model involving pre-positioned trust, bounded credential life, queued evidence, signed transfer, replay refusal and later reconciliation.
- Out of scope
- Universal agent governance, agent-behaviour correctness, vendor integration, standards certification and complete product-wide disconnected identity are not claimed.
Next assurance gate
Trace one selected delegated-identity path through issuer, verifier, lifecycle checks, protected-resource policy and dated release evidence in the target environment.
Plan a Q-Kavach evaluationEcosystem questions, an illustrative scenario and reading
Ecosystem fit
Questions before architecture claims
These are ownership and assurance questions for an evaluator. They do not claim replacement, compatibility or tested integration with another product category.
PKI
Which issuer and verifier paths must change, and how will trust anchors, algorithm roles, rotation and retirement remain explicit?
PAM
Where does privileged human approval end, where does delegated agent authority begin and which evidence explains the boundary?
Illustrative evaluation scenario
A bounded question, not a customer case study
- Context
- A security team is examining one internal agent workflow whose delegated action reaches a protected resource in a controlled evaluation environment.
- Evaluation question
- Can the team prove who authorised the agent, how the child scope narrowed, when the grant expires and what the resource must verify?
- Expected evidence
- A named authority source, signed agent assertion, parent-bound child grant, bounded lifetime and audience, selected replay and lifecycle checks, refusal evidence for an invalid chain and the target resource's own decision record.
- Stop condition
- Stop if the child can widen authority, parent linkage cannot be validated, lifecycle or replay state is not enforced on the evaluated path, or the resource boundary cannot be stated and tested precisely.
02 / Governed data custody
Drushtikosh
A bounded decision for every custody question.
A research-stage platform exploring who may use which organisational device, on which host, for which data and operation, and for how long.
Discuss Drushtikosh Download Drushtikosh brief PDF · 2 pages- Separate decision and key release
- The lab separates Policy Authority decisions from proof-bound minimum release by the Key Authority.
- Access bounded by context
- Principal, host, device, classification and time define the permitted operation on an encrypted data object.
- Continuity with explicit limits
- Software-sealed lab leases bound offline use. Revocation may wait for reconnect or remaining lease expiry.
Explore Drushtikosh architectureInteractive authority boundaries and offline continuity
Two architectural views
See the separated Policy Authority, Key Authority, endpoint, evidence and operator-observation boundaries in the research lab.
View selected: Authority
Governed custody instrument
A decision, a proof, and the minimum material to proceed
Policy decides. A separate Key Authority validates proof. Two shares meet transiently at the authorised endpoint, while the operator console remains outside both authority boundaries.
Research-stage labProcess-separated authoritiesClassification-bounded leasesTamper-evident records
Explore the architecture
Select a region in the plate or use the labels below. The complete architecture remains visible.
Mouse · touch · keyboard
Whole operating context
Custody request
Principal, cryptographic host, device, protected volume, operation, direction, purpose, classification and time form one bounded request.
Boundary: The assembled context carries no authority by itself; it must be evaluated by policy.
Selected: Custody request
Custody & authority controlsDecision context, minimum release and endpoint use
A Policy Authority evaluates the user, host, device, classification, and requested operation. A separate Key Authority validates a short-lived, proof-bound authorisation and releases only the minimum key share. Separated material meets transiently on the authorised host to open an encrypted DVF vault under the permitted access mode.
Decision context
- Principal
- The requesting user and the strength of the identity presented by the managed agent.
- Cryptographic host
- The enrolled host identity, posture, authority epochs, and proof bound into the request.
- Device and volume
- The enrolled storage object, its state, the protected volume, and the material it is allowed to carry.
- Operation and time
- Read or write direction, data classification, requested purpose, online state, and the remaining lease window.
Authority responsibilities
- Policy Authority
- The sole writer for registry, policy, leases, approvals, and enrolment evaluates context and decides whether an operation may proceed.
- Key Authority
- A separate process validates the signed, single-use authority ticket, proof binding, replay state, and epochs before releasing minimum Share B.
- Authorised endpoint
- Share A and Share B combine transiently on the permitted host; the reconstructed material opens only the authorised DVF operation and is not retained as a standing key.
- Read-only console
- The observation view reads state and evidence without holding key material. Exposed administrative actions are routed to the Policy Authority, which retains decision authority.
Drushtikosh evidence & limitsFive evidence states · reviewed 28 September 2026
Dated evidence dossier
Drushtikosh evidence states
States are independent evidence categories, not steps in a maturity score. Implemented and tested do not mean deployed, certified, scaled or independently assured.
- Reviewed
- 28 September 2026
- Revision
- Public evidence review · P11.1
- Implemented
- The lab assembles custody context, contains bounded offline-bundle and lease mechanics, and presents state through read paths while routing exposed administrative actions to the Policy Authority.
- Tested
- Selected lab paths exercise process-separated policy and key decisions, proof-bound minimum release, transient share reconstruction and change-detectable custody evidence.
- Deployment-dependent
- Live host and media enforcement, hardware-rooted expiry, production isolation and revocation or reconnect behaviour depend on the target environment.
- Design proposal
- Production HSM or KMS custody, TPM-backed expiry, durable write-once retention, database-role isolation and a scoped operational rollout remain translation work.
- Out of scope
- MDM, DLP or encrypted-storage replacement, vendor integration, endpoint-protection claims and a combined deployment with Q-Kavach are not claimed.
Next assurance gate
Translate one bounded custody path into the intended host and hardware environment, then verify enforcement, authority isolation, expiry, reconnect behaviour and durable evidence under that exact scope.
Plan a Drushtikosh evaluationEcosystem questions, an illustrative scenario and reading
Ecosystem fit
Questions before architecture claims
These adjacent categories define questions for an evaluation. They do not imply replacement, interoperability, compatibility or a tested integrated platform.
MDM
Which managed-host and enrolled-device facts enter the custody decision, and which target control actually enforces the result?
DLP
Who decides classification, movement direction and purpose, and what evidence shows that an impermissible operation was refused?
Encrypted storage
Who may release the minimum material for one operation and lifetime, and how is it shown that neither share alone is the complete key?
Illustrative evaluation scenario
A bounded question, not a customer case study
- Context
- A regulated operator is examining one managed-host path to an encrypted DVF object, including a bounded period of disconnected operation.
- Evaluation question
- Can the lab show how custody context becomes a policy decision, how proof gates minimum release and what remains knowable before reconnect or expiry?
- Expected evidence
- Bound principal, host, device, operation, classification and time; a Policy Authority outcome; a single-use proof-bound ticket; separate Key Authority validation; transient share use; bounded lease state; queued evidence and an explicit reconnect review.
- Stop condition
- Stop if custody context is incomplete, policy and minimum release collapse into one unbounded authority, the residual offline-revocation window is unacceptable, or target host and hardware enforcement remain unspecified.
Beyond the products
Engineering around your question.
Advisory, engineering and research engagements begin with your operating context and the evidence needed for a decision.
Advisory
Clarify the technical decision before committing to an architecture, programme, or build.
Explore advisory scope
- Technology strategy
- Technical feasibility
- Technology due diligence
- System architecture
- Innovation programme design
Engineering
Translate a defined problem into models, architectures, embedded systems, and focused prototypes.
Explore engineering scope
- System architecture
- Simulation and modelling
- Prototype design
- Embedded and control systems
Research
Investigate questions that need evidence before an engineering path can be chosen with confidence.
Explore research scope
- Contract R&D
- State-of-the-art analysis
- Proof-of-concept development
- Technical documentation
Assurance method
Internal engineering-evidence method
Each claim leads to a repeatable test and dated evidence. This is AstraSutra’s internal engineering method, not external audit, certification, accreditation, formal proof or government authorisation.
Explore the seven-step evidence method
Internal engineering evidence spine
Claim
Artifact · Bounded claim record
State the property, path, preconditions and excluded extension.
Test
Artifact · Repeatable procedure
Exercise the expected result and the relevant refusal or failure condition.
Finding
Artifact · Dated evidence record
Record what the evidence supports, what it does not and which environment produced it.
Remediation
Artifact · Change rationale
Correct the mechanism or narrow the claim when evidence exposes uncertainty.
Regression protection
Artifact · Guard assertion
Preserve the corrected boundary through a repeatable check.
Separate re-verification
Artifact · Fresh review pass
Re-run the evidence from a separate review step without implying external independence.
Dated release evidence
Artifact · Versioned public dossier
Publish the bounded state and next assurance gate for the reviewed release.
The next conversation
Start with one clear question.
Tell us the decision, the environment and what you need to establish. We can begin with a focused evaluation or engineering discussion.
Start a conversation