Data boundaries
Know what enters, where it goes, and how long it remains.Define source-of-truth systems, allowed data classes, minimization, residency, retention, deletion, and which providers may receive each field.
Security & assurance
Your agent can act. You still control what it may do.
Role scope, approvals, operating state, retries, escalation, attribution, observability, and deployment ownership are designed into the system—not added after the build.
Least privilegeExplicit authorityDurable operating recordRecoverable operations
The honest boundary
No inherited trust. No blanket compliance claim.
Assurance is mission-specific. The controls required for a scheduling assistant are different from those required for financial, health, employment, payment, or other protected information.
Lionwork identifies the applicable data, vendors, access, action risk, contracts, operating controls, and evidence with the client. A system enters production only within that documented boundary. If the environment cannot support it, the mission is narrowed, redesigned, or declined.
Nine assurance domains
The system earns authority one boundary at a time.
These are the areas Lionwork expects every production architecture to address. The exact implementation and evidence depend on the mission; inclusion here does not assert a certification or universal control set.
Identity & secrets
Every action uses attributable, revocable access.Use least-privilege service identities, managed secret storage, role scope, rotation, and revocation. Credentials do not belong in prompts, source code, or browser storage.
Agent authority
The system knows the difference between reading and committing.Separate read, prepare, recommend, approve, and execute permissions. Consequential actions receive thresholds, human command points, and a practical stop path.
Durable state & audit
Important runs leave a reconstructable operating record.Persist run state, actor, model or rule version, source references, approvals, actions, write-backs, and terminal outcome with idempotency where repetition creates risk.
Failure & recovery
The failed path is designed before the live path is trusted.Specify timeouts, retries, fallbacks, dead-letter handling, replay safety, escalation, reconciliation, and the person who owns recovery when automation stops.
Environments & release
Experiments do not share authority with production.Separate development, test, staging, and production as risk requires. Control configuration, test data, migrations, approvals, release evidence, and rollback.
Monitoring & support
A system is not installed until somebody can tell when it drifts.Observe availability, latency, usage, cost, quality signals, exceptions, and unresolved work. Define alert ownership, runbooks, response paths, and support expectations.
Ownership & handover
The client should not inherit a black box.Document repositories, infrastructure, accounts, data stores, vendors, credentials, decision rules, operating procedures, administrators, and the route to change or exit.
Regulated-data eligibility
Protected data is an eligibility decision—not an assumption.Classify the data and obligations before it enters scope. Confirm contracts, vendor eligibility, residency, retention, access, and evidence requirements or redesign the mission.
Illustrative agent-authority model
Capability does not equal permission.
An agent can be technically able to take an action without being authorized to take it. Each mission defines its own levels, thresholds, approvals, and stop conditions; this model illustrates the separation.
- 01
Observe
Read permitted sources, retrieve context, classify signals, and surface an exception without changing operating state.
Scoped read access - 02
Prepare
Draft the response, recommendation, record change, or next action with evidence ready for review.
Human reviews the consequential move - 03
Execute
Perform a bounded action only when policy, confidence, authority, and the current operating state allow it.
Attributable action + durable write-back - 04
Escalate
Stop, preserve context, and route to a named person when the path is ambiguous, denied, failed, or outside authority.
Visible exception ownership
Model infrastructure
The Gateway is infrastructure—not the product or the compliance claim.
Where appropriate, Lionwork routes model access through Vercel AI Gateway to centralize model selection, ordered fallback, usage and cost visibility, and routing metadata. Lionwork or client controls enforce budgets.
The approved providers, models, prompt and schema versions, data eligibility, retention, account ownership, action boundaries, and human review rules are still defined for each system. A Gateway does not by itself establish compliance or eliminate provider outages.
Production is client-owned or client-controlled where practical; deterministic business and safety rules remain outside probabilistic output, and model/cloud usage is disclosed as an allowance or pass-through.
Regulated-data eligibility
Protected data changes the architecture before the first prompt.
Regulated or contractually restricted data is not assumed eligible. Lionwork and the client must determine the obligation, required vendors and agreements, geography, retention, access, logging, and incident responsibilities before that data enters scope.
ELIGIBILITY DECISION
01Classify
Identify the data and obligation.
02Qualify
Confirm vendors, contracts, controls, and geography.
03Constrain
Minimize data, authority, retention, and exposure.
04Decide
Proceed, redesign, isolate, or decline.
No statement on this page represents legal advice, a certification, or a promise that every Lionwork architecture is suitable for regulated data. Eligibility is established for the specific mission and environment.
Assurance through installation
Controls become real at delivery gates.
Documents alone do not create command. Lionwork connects the written boundary to technical tests, operating ownership, and the first live cycle.
- 01
Architecture boundary
Name the systems, data classes, identities, vendors, actions, approval points, and recovery owners before detailed implementation.
- 02
Pre-production review
Exercise access, failure paths, duplicate events, model uncertainty, write-backs, audit records, alerts, and rollback against the approved mission.
- 03
Live-cycle stabilization
Observe real runs, reconcile outcomes, resolve exceptions, tune thresholds, and verify that the operating team can command the system.
- 04
Ownership handover
Deliver current architecture, access map, runbooks, decision rules, vendor inventory, operating procedures, and named ownership for the next release.
Bring these questions
Serious buyers should be able to inspect the command boundary.
The useful security conversation is specific: the actual data, identity, action, failure, evidence, environment, and owner behind the mission.
- 01
Which data may enter this mission—and which data is explicitly prohibited?
- 02
Which identity performs each action, and how can that authority be revoked?
- 03
Where can an agent act without review, and what requires human command?
- 04
Can the last material run be reconstructed from source signal to final write-back?
- 05
What happens when a model, integration, queue, or scheduled job fails?
- 06
Who receives the alert, owns recovery, and confirms reconciliation?
- 07
Which environments, vendors, contracts, and evidence does this data class require?
- 08
What will the client own and operate when installation is complete?
Design references—not certifications
Recognized frameworks inform the questions.
Lionwork uses established secure-software and AI-risk guidance as design references. This does not claim organizational certification, attestation, or universal conformance.
NIST SSDF
Secure software development practices and release discipline.
Review source ↗NIST AI RMF
AI risk, measurement, governance, and operational context.
Review source ↗OWASP ASVS
Application-security verification requirements and test depth.
Review source ↗CISA Secure by Demand
Buyer diligence for product security and supplier accountability.
Review source ↗Underwrite the boundary
Bring the mission, the data, and the action it must take.
Lionwork will map what the system may know, decide, change, record, and escalate—then identify what must be true before it enters live use.