Auremere

Security & data

Make the boundaries explicit.

Security decisions belong in the workflow design. The following are our delivery standards; actual hosting, access, retention and provider settings must be agreed and verified for each engagement.

Three distinct responsibility boundaries
Three distinct responsibility boundaries. Reference data flow: client-approved context goes to an approved model; proposed actions return to validation. Auremere access is separately granted. Client-controlled systems Identity · source data · execution Client approves access and actions Application control layer Minimise context · validate tool calls Policy + logging + human review Approved model provider Inference under selected account terms Auremere: scoped delivery access No blanket access to client systems
Reference data flow: client-approved context goes to an approved model; proposed actions return to validation. Auremere access is separately granted.

Data and access

Decide what may cross each boundary.

Location and provider terms

Identify the storage and processing locations for source data, model requests, evaluation sets, logs and backups. Record which approved services may process each category. We do not claim that all data stays in one jurisdiction or in a client environment: model processing can cross that boundary and requires an explicit decision.

Before connecting a provider, review the selected account’s region, retention, training-use terms, subprocessors and deletion options. Do not assume that one provider policy applies to every product or account tier.

Least-privilege access

Prefer client-owned environments and accounts. Use named, time-bounded identities with only the required permissions; separate test and production access. Keep secrets in the approved secret store, not in prompts, documents, repositories or general logs.

Untrusted content is not authority

Retrieved documents and user inputs may contain hostile instructions. Enforce tool allowlists, argument validation and access checks in application code. A model response must not grant itself permissions.

Access lifecycle
Access lifecycle. Access is approved for a specific task and environment, reviewed as scope changes and removed at closure. 1 Approve Owner + purpose + environment 2 Provision Minimum scope + expiry 3 Review Access record + change history 4 Revoke Close access + record completion
Access is approved for a specific task and environment, reviewed as scope changes and removed at closure.

Human review

Stop before an unsafe action.

Define review triggers with the business owner. Examples include irreversible changes, payments, permission changes, sensitive disclosures, conflicting evidence and actions outside the agreed scope.

For financial workflows, preparing an analysis is different from executing a transaction. A proposed external message is different from permission to send it.

Give the reviewer enough context

Show the proposed action, affected records, supporting evidence and the reason for escalation. Record who approved, rejected or amended it. If approval expires, the reviewer is unavailable or evidence is insufficient, hold the action and route to the agreed owner.

Make limits enforceable

Set tool allowlists, spending caps, retry limits and timeouts in the application. Pause automation on policy violations, repeated validation failures or a breached operating limit.

Action and escalation path
Action and escalation path. Review is triggered by explicit rules, not by relying on a model to report its own confidence. Proposed action Policy + validation check Permission · evidence · impact Within scope Low-risk + validated Execute and record Review required Ambiguous / high risk Hold before action Approve · amend · reject No reviewer → remain on hold
Review is triggered by explicit rules, not by relying on a model to report its own confidence.

Logs, retention and incidents

Useful evidence without unnecessary copies.

Trace the decision

Capture task identifiers, configuration versions, tool outcomes, approval events and error categories. Prefer metadata and redaction over full payloads. If sensitive content is necessary for diagnosis, agree restricted access and a short retention window first.

Agree retention by purpose

Set retention and deletion rules separately for enquiries, client data, traces, evaluation cases and backups. Record where deletion is controlled by a third-party provider and what evidence is available. Do not promise instant removal from systems outside the agreed scope.

Contain before continuing

On a suspected data or permission incident, pause affected actions, preserve appropriately restricted evidence and notify the designated client owner under the agreed procedure. Revoke or rotate access where authorised; resume only after review.

Close the engagement

Inventory project data and access. Return agreed artefacts, revoke delivery accounts and record deletion or retention exceptions. Retain only what is authorised or required by the applicable agreement and law.

Model and supplier changes

Treat a new model as a system change.

A model update can alter output, tool use, latency, cost and data-handling terms. Pin versions where available; record dependencies that can change without a fixed version.

  • Review provider and processing-term changes before use.
  • Run the versioned evaluation set and compare failure modes.
  • Check budget, latency, safety rules and integration behaviour.
  • Obtain approval for a limited release and keep a tested rollback route.

Provider outages should lead to a defined hold, fallback or escalation. A fallback provider must be approved for the data involved; switching providers is not automatically permitted.

Controlled change
Controlled change. No silent substitution of models or providers across an agreed data boundary. 1 Record the proposal Version + purpose + data terms 2 Evaluate the candidate Quality + safety + operating limits 3 Approve a limited release Named owner + observed rollout 4 Monitor or roll back Compare results + preserve baseline
No silent substitution of models or providers across an agreed data boundary.

Have a data-handling constraint?

Describe the requirement without sending confidential records or credentials.

Discuss a project