Tegata: Time-Boxed Access, Signed by a Human

Time-boxed privileged access: an AI drafts the request, a human signs a real document, Xano enforces it live, and access auto-expires -- no standing permissions, no forgotten cleanup.

Comment

Inspiration

Standing privileged access — the kind that sits on an account forever until someone remembers to revoke it — is one of the most common real security gaps in actual companies. Tegata asks: what if access was never standing at all? What if every grant was time-boxed by design, required a human signature on a real document to exist, and closed itself automatically when the window ran out?

What it does

Tegata is a time-boxed access authorization system:

  1. A requester describes what they need in plain text. A two-pass LLM step (extraction, then self-check) turns that into a structured request — but the LLM never has the final say. Hard schema validation is the real gatekeeper underneath.
  2. Xano scores the risk and decides how many approvers are required.
  3. Doctavian generates the actual grant document — with clauses that genuinely change based on risk tier, not a cosmetic label.
  4. A human reviews and signs the document through Foxit eSign. The AI agent's role stops here entirely — signing is architecturally impossible for it to do.
  5. Xano's state machine activates the warrant, rejects any attempt to replay the signature, and auto-expires it when the approved window ends.
  6. The proof, not just the claim: a real protected-resource gateway independently asks Xano, fresh, on every single request, whether the caller currently holds an active warrant — before releasing anything. Try it yourself: hit /resource/internal_wiki before requesting access (denied), after signing (granted, with a live expiry timestamp), and after it expires (denied again, automatically).

Beyond the core loop: a hash-chained, independently-verified audit log; Doctavian-powered progressive disclosure (technical details withheld until a first signature exists) and dual-audience document generation (one warrant → a formal grant doc + a separate operator runbook); Xano-enforced RBAC that makes one user's data structurally invisible to another; extension requests that create their own approvable request rather than silently modifying a grant; and a synthetic canary that health-checks the whole scoring pipeline every 15 minutes.

How we built it

  • Xano: the entire backend — risk scoring, state machine, RBAC across every endpoint, hash-chained audit log with an independently-verifiable hash-chain endpoint, and a scheduled canary task.
  • Doctavian: document generation using their conditional-paragraph templating (mdoc:paragraph hidden="{!$expression}") — not just a template with fields swapped in, the document's actual structure changes based on risk tier and signature state.
  • Foxit eSign: real embedded signature flow. The signing boundary is architectural, not a convention — the AI agent has no code path that can call the signature step.
  • Next.js/TypeScript frontend, deployed on Railway. Python reference implementations with full pytest coverage backing the risk engine, state machine, and audit hash-chain logic before any of it touched Xano.
  • Built with Claude (Claude Code) throughout, including catching several real bugs that only surfaced under actual cross-account, cross-role testing.

Challenges we ran into

  • Getting Xano's own AI-agent-generated Function Stacks to actually match a tested Python reference implementation exactly — several rounds of "looks right" that weren't, caught by cross-checking Xano's answers against independently-recomputed results rather than trusting either source alone.
  • Doctavian's OAuth token has no working refresh flow for this integration — solved with a documented manual-renewal runbook rather than pretending a fix existed that didn't.
  • Building an actual enforcement proof (the resource gateway) instead of letting "access granted" mean nothing more than a status field changing color in a dashboard anyone could edit by hand.

What's next for Tegata

Real Slack/email notifications on canary failure (currently logs only), auto-triggering progressive disclosure on signature events instead of manual reveal-level calls, and extending RBAC's cross-tenant filtering to a second live-tested endpoint pass.

--

Sponsor Details

  • Doctavian: Doctavian does the real work in progressive disclosure and dual-audience generation: the same warrant data produces a document that withholds technical execution details (the literal grant command) until a first approver has signed, and separately generates a formal grant document plus a completely different operator runbook — both driven by Doctavian's own conditional-paragraph templating, not two hand-written templates or a post-processing hack.

  • Xano (Build Story): Tegata replaces the informal mix of Slack messages, standing IAM roles, and "remember to revoke this later" that most teams actually use for temporary privileged access — software everyone has but nobody trusts. We chose to rebuild it because the gap between "requested" and "actually time-boxed and enforced" is almost always just a human forgetting a step, which is exactly the kind of gap a backend can close by design instead of by policy. Xano powers the entire backend: risk scoring, the full approval state machine, RBAC across every endpoint (verified with real cross-account tests, not just read from the Function Stack), a hash-chained audit log with its own independent verification endpoint, and a scheduled canary task that health-checks the scoring pipeline every 15 minutes. We built with Claude (Claude Code) throughout — for both the Python reference implementation and the Next.js frontend, and for the iterative Xano Function Stack verification loop (propose a prompt for Xano's own AI agent, get its response, verify the result against tested reference code rather than trusting the description). Total build time was roughly 10 days. Without AI assistance, the parts that would have taken significantly longer: writing and cross-checking the RBAC Function Stack logic by hand across five separate endpoints, and building the hash-chain audit verification loop with a genuinely independent second implementation to check it against — both are exactly the kind of "looks right, isn't quite" work that benefits from having two independently-generated answers to compare instead of one.

  • Foxit: The agent's authority ends the instant a document needs a signature — there is no code path, prompt, or API credential available to it that reaches Foxit's signing endpoint. The workflow: the agent (via Doctavian) proposes and generates the grant document; a human approver then explicitly initiates a real Foxit eSign envelope and signs it themselves through Foxit's own embedded interface. Only after that human action does Xano's state machine activate the warrant. We also treat "already signed" as a hard boundary, not just a UI state: attempting to reuse an already-active warrant's signature is rejected by Xano's own state machine, reproduced and confirmed during testing, not left as a theoretical guarantee.

--

Demo Accounts & Troubleshooting

To test the live application at our Try-it-out link, please use the following pre-configured accounts (Password for all: tegata123):

⚠️ Important Testing Notes:

  • AI Front-Door / NLU: If you encounter an API error when clicking "Fill form from description", please wait a few seconds and click the button again.
  • Doctavian API: Doctavian utilizes strict 1-hour OAuth 2.0 tokens. If you test the application and encounter a "Doctavian API Error" on the Approver screen, it means the hackathon demo token has expired. Please email me immediately at [email protected] and I will refresh the server token for you within minutes so you can proceed with the signing flow.

Built With

Share this project:

Updates

Submission history