The authorization layer for automated systems
The signed record of who accepted the risk, what the system may do, and until when.
A search through Slack, email, and Jira should not be the only way to find out.
In licet, inspect the permitted actions, exclusions, conditions, and named risk acceptor together. The example below shows how that decision is recorded.
This sample demonstrates where an evaluation attachment would appear in the record. No evaluation was performed for this illustration. It contains no evaluator, findings, test results, or assurance opinion and is not part of the signed public demonstration record.
How your team uses licet
Describe the system, permitted actions, environments, and explicit exclusions.
Connect conditions to sources and interpretations. Gather concurrences and name the person accepting residual risk.
Preserve the approved version, its conditions, and its expiry. Export the record for independent verification.
Use the Registry to identify approaching expiry and records needing attention. Revisit authorization when scope, policy, or authorities change.
The working prototype supports this record lifecycle. Production integration and operational assessment are separate work.
Make the boundaries of automation explicit. See what has been authorized, which conditions apply, and where permission ends.
Keep institutional decisions connected to their sources, interpretations, and owners. Produce the record when someone asks.
Find your systems and their authorization records. See which records need attention and which are approaching expiry.
Explore with us ↗Bring scope, conditions, exclusions, and the named risk acceptor together in a signed, versioned record.
Inspect a signed demonstration record ↗Inspect the source and attributed interpretation behind a condition, alongside its policy reference and evidence requirements.
Explore with us ↗Produce an audit memo and Cedar policy set from the same record. Check the signed record independently.
Inspect a signed demonstration record ↗Optional runtime enforcement. Check proposed actions against the recorded authorization before they proceed. Production executor integration is required.
Co-Founder
Twenty years across seven federal agencies, where no system goes live until a named official accepts its risk in writing. licet brings that discipline to every automated system. American Service Fellow in the Mid-Career MPA program at Harvard Kennedy School. MA in Strategic Studies, Air War College.
David’s story at Harvard Kennedy School ↗Co-founder
Swiss lawyer and former compliance lead for a Swiss cantonal government. MC/MPA candidate at Harvard Kennedy School, selected as Switzerland’s representative on a Harvard sovereign AI project.
Preserve the institution’s decision in a form that product, policy, legal, and independent reviewers can examine.
Read the signed demonstration record ↗An authorization record documents institutional permission.
Keep the risk acceptance and concurrences attached to the version that was approved.
Preserve the sources, interpretations, limits, and evidence requirements behind the decision.
Demonstration signatures establish no real-world identity or approval. Operational assurance is not assessed; legal compliance is not determined. This is a fixed snapshot, not a current authorization check.
Now selecting design partners.
For teams running a consequential automated workflow, with a workflow owner, an engineering counterpart, and policy or risk reviewers ready to participate.
Together, we define one bounded workflow, exercise it with synthetic or approved de-identified cases, and assess whether a limited integration is justified. You receive a versioned authorization record, decision rationale, evidence-gap report, and proposed integration and measurement plans.
After you submit, licet reviews your introduction and responds to discuss fit. Scope, timing, responsibilities, and commercial terms are agreed before work begins.