Security & governance
Reduce access. Define authority. Verify results.
Security starts by removing unnecessary access and autonomy. We design controls around the whole workflow: the data it receives, the tools it can use and the actions it may execute.
The Novaria Authority Model
What AI can do. What it may do.
Technical capability does not confer authority. Each workflow receives the minimum authority required for the task, enforced by the software around the model.
Level 1
Read
Search · understand · summarise
Find and explain information from approved sources, within the user's access rights. No changes to business systems.
Controls in place
Level 2
Recommend
Classify · draft · suggest
Prepare a proposal with the context needed to check it. Your team decides what to use.
Controls in place
Level 3
Act with approval
Create · update · synchronise · send
A permitted action reaches your systems only after validation and explicit approval from the responsible person.
Controls in place
Level 4
Automate
Execute within agreed limits
Execute predefined actions without individual approval only where the task is bounded, tested and sufficiently low-risk. Exceptions require review, with monitoring and stop controls in place.
Controls in place
More autonomy is not automatically better. These are operating choices, not a ladder to climb.
Checks around an action
- 01Access boundary
- 02AI / automation
- 03Validation
- 04Human control
- 05Controlled action
- 06Audit & monitoring
Approval is required where the workflow’s authority demands it. Failed validation blocks execution at every authority level.
These are our design principles. We agree the specific controls, hosting and responsibilities for each project. This is not a certification claim.
Access control
- Risk
- AI or a connected tool accesses information outside its task.
- Implementation controls
- Authenticate users and service accounts. Enforce role-based authorisation, least privilege and scoped API access in the application and destination systems. Store credentials outside prompts, rotate secrets and review access.
Data boundaries
- Risk
- Sensitive information reaches a model, store or person that should not receive it.
- Implementation controls
- Map approved and excluded data before implementation. Minimise or redact payloads, isolate client data and specify encryption, storage, retention and deletion. Apply access rules to retrieval as well as the final response.
AI-specific security
- Risk
- An email or document tries to override instructions, expose data or misuse a tool.
- Implementation controls
- Treat retrieved content as untrusted data. Isolate it from system instructions, test prompt-injection attempts and detect suspicious content where practical. Enforce tool allowlists and permissions outside the model; validate outputs before another system consumes them. Detection alone is not a security boundary.
Action control
- Risk
- A plausible proposal triggers a sensitive or excessive action.
- Implementation controls
- Define permitted actions, transaction limits and named approvers. Bind approval to the exact action and data; changes require fresh review. Provide rejection, escalation, cancellation and human override. Stop controls must disable execution, not just hide the interface.
Validation and precision
- Risk
- A confident answer or correctly formatted output is still wrong for the task.
- Implementation controls
- Validate schemas, required fields and business rules. Evaluate representative tasks and failure cases against acceptance thresholds. Use confidence signals only alongside evidence and checks. Route uncertainty to review or a defined fallback; a valid schema is not proof of factual accuracy.
Monitoring and audit
- Risk
- An action cannot be explained, or quality deteriorates unnoticed.
- Implementation controls
- Record input references, model and prompt versions, proposed decisions, validation, approvals, actions and outcomes. Restrict log access and filter sensitive content. Monitor errors, quality, latency, cost and exceptions with named alert owners and agreed retention.
Incident handling
- Risk
- A workflow behaves unexpectedly and continues acting.
- Implementation controls
- Agree detection and escalation routes. Contain the issue by disabling affected actions or credentials, preserve relevant evidence, investigate and restore only after checks. Review the cause and update controls. Response responsibilities and service expectations are defined per engagement.
Providers and models
- Risk
- A provider receives unexpected data or a model update changes behaviour.
- Implementation controls
- Document provider access, processing locations, retention terms and dependencies before sending data. Choose models for the task; record versions and evaluate changes before release. Agree rollback, export and replacement paths to limit unnecessary lock-in.
Deployment and recovery
- Risk
- A service outage, exposed secret or integration change interrupts the operation.
- Implementation controls
- Review hosting and network boundaries, deployment access, secret handling and patching. Define backup, restore and recovery objectives, test recovery and provide a manual or conventional-software fallback where the workflow requires it.
Change management
- Risk
- A prompt, rule or software update bypasses controls that previously worked.
- Implementation controls
- Version prompts, models, rules and integrations. Review code and dependencies, test security and task performance, document release decisions and retain a rollback path. Reassess permissions and authority when scope changes.
Shared responsibility
- Risk
- Technical controls are undermined by incorrect permissions or unclear ownership.
- Implementation controls
- Novaria is responsible for the implementation and operation within the agreed scope. Clients own source-system permissions, data suitability, named approvers and organisational policies. Provider responsibilities, incident contacts and access reviews are documented together.
Governance and requirements
- Risk
- The implementation does not reflect the organisation’s obligations or internal policies.
- Implementation controls
- Controls can be mapped to requirements identified by the client’s legal or compliance advisers. Document data flows, authority, evaluations, changes and ownership. Legal determinations remain with qualified advisers; this is not a certification or a blanket compliance claim.
Security contact
Report a security concern.
Contact the founders through the Company page to arrange a suitable reporting channel. Share only a brief description initially; do not send credentials, personal data or exploit details through a public enquiry.
Tell us what needs protecting.
We'll discuss your data, access rules and approval needs before we plan the build.