Start with one workflow
A smaller team can begin by clarifying one AI use case, its information sources, and who may approve action. A risk review can identify which controls need attention before a broader investment.
Qitronix / Organizations & research
Accountable delegation for AI actions.
Qitronix’s agent authorization and assurance work helps organizations translate authority over AI actions into enforceable controls and verifiable evidence. Begin with one bounded workflow. Bounded Superintelligence is the broader research vision.
01 / Services
A concrete question. A defined deliverable.
Inquiries are welcome for the services below. Availability, a qualified delivery team, scope, schedule, and terms must be confirmed in writing. Proposed pricing is a planning basis; it is not a finalized offer or guaranteed delivery cost.
| Engagement | Purpose | Deliverable |
|---|---|---|
| Enterprise discovery consultation | Clarify one organizational AI question and decide whether a technical review would be useful. | 60-minute session and written brief. |
| Executive architecture session | Connect an executive decision to the system boundaries, responsibilities, and interfaces it depends on. | 90-minute session and written technical summary. |
| AI Risk-to-Control Review | Map a defined AI workflow’s risks to concrete controls, responsible owners, and evidence requirements. | Workflow and information-boundary map; risk-to-control matrix with named responsibilities. Inventory up to three current AI practices for the scoped workflow; identify approved tools, shared instructions, accountable ownership, backup responsibility, and continuity gaps. Dependency and exit-readiness inventory: provider, model, compute, identity, storage and update dependencies; accountable owners, replacement paths and withdrawal consequences. A customer policy and evidence export inventory, continuity and human fallback requirements, and a scoped provider-switch test plan. Executed testing and recovery validation require express inclusion in the written scope. Prioritized findings, control gaps, and a practical remediation plan. A prioritized customer outcome: control, action evidence, or review efficiency; a documented current alternative and measurable baseline for the agreed scope. An evaluation plan identifying test cases, acceptance criteria, evidence gaps, review responsibilities, and a handoff test for another authorized operator. |
| Agent Authorization Design Sprint | Design how agents receive bounded permissions, request approval, use connected tools, and leave evidence that people can inspect. | Authority map and trust-boundary diagrams; accountable owners, delegation lineage, bounded permissions, and receiving-system enforcement. Integration specifications, audit requirements, and designs for denial, revocation, interruption, and recovery. Provider replacement and customer exit design: stable authority contracts, versioned policy and evidence formats, migration responsibilities, and acceptance tests for the replacement environment. Production export and failover implementation are separately scoped. Acceptance tests for allowed actions, excessive amounts, changed payees, expired approvals, replay, and privilege transfer; evidence requirements and an implementation handoff. A change-qualification plan for model, prompt, tool, memory, and workflow changes: retest triggers, version evidence, owner approval, and rollback or safe-stop criteria. Recurring reviews and test execution require an agreed scope. |
The Agent Authorization Design Sprint covers technical architecture, interfaces, and a testing plan. Multiple workflows, integrations, and specialist effort increase scope. Implementation and executed testing are included only when the agreement says so.
Accountable delegation
Start with one consequential workflow.
Illustrative evaluation: an invoice agent may prepare a payment request within an approved amount, payee, purpose, and time window. The receiving payment system must enforce the mandate outside model reasoning. This is a proposed test scope; no customer deployment or result is claimed.
| Institutional question | Proposed work product |
|---|---|
| Who may delegate? | Authority map: legitimate authority source, accountable owner, agent identity, scope, and permitted delegation. |
| Where are limits enforced? | Receiving-system control design and tests for excessive amounts, changed payees, expired approvals, replay, and privilege transfer to another agent. |
| Can an action be investigated? | Evidence requirements linking the authority and delegation chain, approval, policy version, request, and observed effect. |
| When may autonomy expand? | Predefined acceptance tests and a recorded owner decision based on measured results. |
| What happens when agents stop? | Hold conditions, external revocation, human fallback, service continuity, and tested recovery, including effects that cannot be undone. |
Compare against capable existing access controls, transaction limits, sandboxing, and protected approvals. Measure unauthorized effects, legitimate task success, evidence completeness, revocation delay, recovery, latency, and operating cost. External authorization alone does not establish a competitive advantage.
Make useful AI practices transferable.
Begin by comparing up to three ways people already use AI for the workflow. Record approved tools, input boundaries, tested templates, quality checks, and undocumented workarounds. Identify the accountable owner and an authorized backup, then keep reviewed instructions in an organization-controlled location.
Test the handoff: another authorized person should be able to find the current inputs and instructions, reproduce an acceptable result, and follow the fallback procedure when the usual operator or tool is unavailable. Record gaps and review changes before adopting them. Shared instructions support continuity; permission to take a consequential action still requires its own controls.
Demonstration plan: follow one mandate through its result
Use synthetic invoices and a mock payment service. Run the same workload with a competent conventional control baseline and the candidate design. This plan is unexecuted; the website does not process payments or establish runtime readiness.
- Grant a limited mandate
An accountable person specifies the agent, payee, amount ceiling, purpose, expiry, and whether delegation is permitted.
- Request a consequential action
The agent submits the proposed transaction with its mandate reference and a unique request identifier.
- Check at the receiving system
The mock payment service checks identity, policy, scope, expiry, and revocation before producing any effect. Model reasoning cannot override the check.
- Observe allowed and blocked effects
A valid request produces exactly one permitted synthetic transaction. Changed payees, excessive amounts, stale approvals, and replay attempts must produce no unauthorized effect.
- Connect the evidence
Link the mandate, policy version, request, decision, and actual result. Preserve blocked attempts and partial failures alongside successful actions.
- Exercise revocation and recovery
Revoke the mandate, interrupt the agent, and retry an incomplete task. Verify enforcement delay, duplicate prevention, reconciliation, and the human fallback before resuming.
| Measure | What to record |
|---|---|
| Unauthorized-action blocking | Blocked violation attempts / all violation attempts, by attack class, plus the count of actual unauthorized effects. Refusal text alone is insufficient. |
| Legitimate-task completion | Correctly completed authorized tasks / all authorized tasks, including false denials and duplicate effects. |
| Added latency | Paired baseline and candidate timing under the same workload; report median and tail latency, sample counts, and measurement conditions. |
| Evidence completeness | Attempts with a complete mandate-to-result chain / all attempts, including denials, errors, and interrupted requests. |
| Revocation and recovery | Time from revocation to enforcement; time from interruption to reconciled service restoration; unresolved and irreversible effects. |
| Business value and cost | Baseline and candidate task time, compute cost, and human review time. Record risk assumptions separately from observed prevented effects. |
Set the corpus, task-success thresholds, overhead budgets, and recovery limits before running trials. Preserve the exact candidate and baseline versions, fixtures, logs, failures, and uncertainty so another reviewer can reproduce the comparison. Expand authority only after a separate owner decision on the evidence.
Reassess capability while preserving authority.
For a scoped engagement, agree when to revisit previously unsuccessful tasks and what changes trigger review: a new model, revised prompt, connected tool, memory configuration, or workflow. Compare the candidate with the current version using the same task and control requirements. Record task quality, unauthorized effects, review effort, latency, and cost before deciding whether a change is useful.
Keep the current version when the evidence does not justify replacement. Adoption requires an accountable owner’s decision on the tested configuration, its permitted effects, and a recovery plan. Better capability does not expand permissions. Recurring reassessment is separately scoped; this proposed method establishes no continuous monitoring service or completed qualification.
Research extension: governed improvement
Let an agent improve a small software component in isolation. Challenge attempts to alter protected tests or policy, widen permissions, substitute an approved artifact, reuse expired approval, or bypass a boundary through another agent. Candidate changes must not control the authorizer, credentials, release controls, or externally held evaluation evidence.
Promotion requires separate authorization bound to the exact artifact, policy, environment, and permitted effects. Improved capability must never automatically confer expanded authority. These are proposed acceptance requirements; passing one bounded experiment would not establish recursive AI safety.
02 / Organizations
Match the engagement to the team and its responsibilities.
Potential audiences include smaller businesses, educational and nonprofit organizations, university research groups, financial services, cloud providers, enterprise AI teams, and government laboratories.
Scope specialized environments
Enterprise, financial, cloud, and laboratory work may require additional integration design, procurement requirements, security review, and specialist resources. Sector relevance is a scoping opportunity; it does not establish certification, a customer deployment, or regulatory approval.
03 / BSI research
Research has its own agreement and evidence.
Investigate a bounded BSI research question through a milestone-based agreement with explicit methods, evidence, and review decisions. Pricing is by custom quotation.
Milestones and review
Agree research questions, methods, baselines, milestones, deliverables, IP rights, and stopping conditions. Reports must distinguish demonstrated results, design proposals, and open questions. Experimental success is not guaranteed.
Current availability
Qitronix BSI runtime deployments remain experimental and require separate readiness evidence and release approval. Advanced robotics, photonics, and quantum applications are research opportunities. Advisory work does not grant software access or activate a runtime.
04 / Next step
Bring a non-confidential question.
Describe your organization, one workflow, desired outcome, timing, and the kind of help you need. Confirm fit and delivery resources before commissioning work.
Confidential review begins only after agreed confidentiality terms and a suitable transfer method. This site does not execute an NDA or provide an activated NDA-gated document service. Keep proprietary materials out of the first inquiry.