Security, discretion, and authority

Access to information and authority to act are separate controls.

Autonomy engineering requires enough company state to build a useful successor. It does not require blanket access or unrestricted action. Every source, purpose, person, tool, action, limit, and retention rule is defined for the client, and operating authority can be narrowed or revoked.

Review the control model See the technical architecture

Written scope answers six questions before a connection begins.

Permission is specific enough that a qualified owner can understand what enters, why it enters, and what remains outside the engagement.

Access to information

Which sources?
The exact email, CRM, ERP, accounting, document, portal, communications, or other operating surfaces approved for the work.
Which records?
The categories needed to reconstruct company state and decisions, together with privileged, personal, regulated, credential, or other excluded material.
For what purpose?
Decision reconstruction, operating memory, successor improvement, evaluation, managed operation, the Succession Dossier, or another explicitly agreed client purpose.
Who and what may use them?
The named people, client-specific systems, and approved service providers assigned to each purpose.
How long are they retained?
Retention, revision, deletion, return, legal hold, and end-of-engagement treatment are defined for the client.

Authority to act

What actions are allowed?
Observation, recommendation, approval, execution, escalation, administration, and audit remain separate permissions.

Use the least invasive connection that preserves the required state.

Reliability and control improve when the successor uses structured interfaces instead of imitating a person at a screen.

  1. APIs first

    Approved APIs provide structured access, scoped permissions, clear inputs and outputs, and a stronger basis for validation and audit.

  2. Structured imports next

    Read-only database access, exports, archives, files, and scheduled imports can reconstruct history without granting a system the ability to act.

  3. Controlled browser or computer use as fallback

    When a required legacy surface has no reliable interface, the successor works inside a constrained session with approved destinations, isolated credentials, recorded actions, and explicit permission.

  4. Eumen conversations remain grounded and scoped

    Voice and review sessions use approved episodes to recover judgment. They do not create new permission for unrelated records or actions.

Autonomy does not mean the absence of controls.

The successor can operate proven work independently while the surrounding control system continues to enforce scope, limits, logging, escalation, and revocation.

Client separation
Each client’s source material, operating memory, tools, policies, evaluation cases, credentials, and authority rules remain inside that client’s operating boundary.
Minimum necessary access
People and systems receive only the information and functions required for their assigned work, with broader access treated as an exception to justify.
Credentials outside operating memory
Passwords, keys, and other secrets are isolated from the memory and decision records used to reconstruct company judgment.
Restricted-material quarantine
Excluded, privileged, regulated, personal, or suspicious material stays outside working context or is routed for review.
Reviewable activity history
Access, retrieval, recommendations, approvals, actions, escalations, corrections, errors, and authority changes remain reviewable at the agreed level.
Incident response
Detection, containment, authority reduction, investigation, client communication, remediation, and recovery responsibilities are defined in the operating procedures and signed terms.

Knowing how to act does not create permission to act.

Authority is granted by decision class and risk, outside the model’s own confidence. The control system can stop, narrow, or reverse it.

  • Allowed tools and destinations

    The successor can reach only the applications, accounts, functions, and external destinations approved for the current class of work.

  • Risk and value limits

    Financial exposure, reversibility, relationship sensitivity, novelty, confidence, and policy determine whether work may proceed or must stop.

  • Point-of-action approval

    Unproven or sensitive actions pause immediately before the consequential step rather than relying on broad approval given earlier.

  • Escalation with context

    The right person receives the issue, relevant state, proposed path, missing facts, downside, and reason the successor stopped.

  • Authority contraction and revocation

    Drift, severe error, missed escalation, changed conditions, or a client decision can reduce or remove authority without waiting for the system to agree.

  • Recovery and rollback

    Where the operating surface permits it, actions have a defined reversal, containment, or recovery path before broader authority is granted.

Legacy systems run inside a constrained, reviewable workspace.

Some legacy applications require screen, pointer, and keyboard interaction. Those surfaces receive tighter controls because the interface itself can be ambiguous or untrusted.

Constrained environment
Use an isolated browser, workbench, or session with approved applications, domains, accounts, and files.
Read-only by default
Observation and reconstruction begin before write access. Each action class must earn its own permission.
No unmanaged credential exposure
Credentials remain isolated from general model context and are supplied only to the approved action path.
On-screen content is not permission
Instructions found in a page, message, file, or interface cannot grant authority or override the client’s operating rules.
Recorded and reviewable actions
Screens, proposed actions, approvals, execution, and results are logged at the level needed to investigate error and recover state.

Private review covers the systems, vendors, data uses, actions, retention, incidents, deployment, and ownership arrangement.

Before granting deep access, a qualified client can review the specific operating boundary proposed for its company.

  • System and data inventory

    Approved sources, connection methods, service providers, sensitive categories, excluded material, and the operating need for each source.

  • Access and authority matrix

    Which people and systems can inspect, recommend, approve, execute, administer, revoke, and audit each material class of work.

  • Lifecycle and incident terms

    Retention, revision, deletion, notification, containment, recovery, transition support, and end-of-engagement responsibilities.

  • Tailored deployment and operation

    The plan defines the mix of Eumenon-managed operation, client operation with Eumenon maintenance and improvement, and shared responsibility, including who governs, supports, and owns each part after deployment.

DISCRETION

The work is private because the operating history is sensitive.

Client identity, operating history, metrics, successor performance, Dossier evidence, and transition plans remain private unless the client authorizes disclosure.

Begin with qualification See what the Dossier records

This page is a high-level operating description, not a security addendum, privacy notice, audit report, or contractual representation. Client-specific obligations exist only in signed agreements.