AMOS is the single governed path between an AI operator and company systems: identity, tenant scope, credentials, policy, approvals, execution, and proof stay in one control plane.
Desktop never needs a business-system token. The same rule applies to Claude, Codex, and every other MCP client.
Authenticated intent, not connector authority.
Tenant · RBAC · policy · approval · vault · execution · receipt
Only capabilities advertised as available by AMOS Platform.
AMOS Desktop can ask the Platform to do real work, but it does not receive blanket authority. Every company action passes through identity, tenant scope, RBAC, connection policy, and—when consequential—a separate human decision.
Company-system tokens never enter Desktop or the model. Desktop sends authenticated intent to AMOS Platform, which resolves the tenant-bound connection and the specific capability allowed.
The model cannot grant itself a role, expand a connector scope, activate a user, or outrank the person operating it. Tenant, role, user scope, key scope, and connection ownership are checked server-side.
Reading a metric is different from sending mail, publishing content, assigning training, spending money, or deleting data. AMOS classifies the business operation and fails closed when it cannot classify it safely.
Consequential operations stop as pending decisions. A verified human reviews the exact operation and bounded arguments through a separate ceremony; ordinary OAuth clients and API keys cannot approve.
Before execution, AMOS rechecks tenant, role, pending state, idempotency, and the original request. A denial, expired challenge, changed operation, or lost authority stops the action.
Owners can deny pending work, disable a goal or automation, deactivate a user or key, disconnect an application, and inspect receipts. Those controls do not depend on the model cooperating.
Desktop workspace tools remain limited by the operating-system permissions and project roots the user selected. They do not receive business-system credentials. Outlook, Power BI, Nuvola, and other company actions still use the governed Platform/MCP path.
These are product controls in the current AMOS architecture, not a claim of third-party certification.
The authenticated AMOS connection fixes the company boundary. Role and scope checks limit every user and key, while protected tenant tables use PostgreSQL row-level security.
Connected-system secrets and OAuth token sets remain in the AMOS Platform vault. Connector credentials are AEAD encrypted with ChaCha20-Poly1305 and are never returned to Desktop or the model.
AMOS distinguishes a read from a draft, publication, assignment, spend, external message, or deletion. Unknown operations fail closed instead of inheriting a convenient transport label.
Consequential work can park with exact context for a signed-in decision. Verified Desktop approvals use a one-time server challenge and installation-key signature; API keys cannot approve pending work.
Governed consequential operations create durable receipts linking actor, tenant, policy, bounded inputs, execution result, verification state, and time without exposing connector credentials.
Desktop, Claude, Codex, and other MCP clients call AMOS Platform. Business capabilities do not become safer or less safe based on which model or interface initiated them.
Owner, admin, member, and viewer roles set privilege ceilings. Per-user scopes can be narrowed, custom roles cannot introduce owner-only authority, and inactive users are refused.
API key scopes are intersected with the issuing human’s role and effective authority. Platform-operator scopes require explicit owner issuance and additional tenant pinning.
AMOS classifies the business operation, not merely the HTTP method. This is essential for APIs and MCP servers where reads and high-impact writes all travel over POST.
The platform resolves the authorized connection and upstream organization. Call arguments cannot redirect work into another company.
Connector execution blocks loopback, private, link-local, wildcard, and cloud-metadata destinations to reduce SSRF and credential-exfiltration risk.
Receipts identify the actor and whether a personal or shared service-account connection executed, without disclosing the secret.
The security conversation extends beyond AI approvals. AMOS documents the standard enterprise control areas and distinguishes product controls from deployment-specific assurance.
Nuvola is live and can generate courses with AI today. The target AMOS integration uses the same canonical platform path so course creation does not become a Desktop-only, unaudited capability.
AMOS identifies and cites a measurable performance gap.
It searches existing learning and drafts a grounded intervention.
A human reviews course construction, publication, and learner impact.
Once enabled, AMOS invokes the tenant-bound Nuvola MCP connection server-side.
Completion and later operating metrics close the evidence loop.
AMOS currently catalogs Nuvola as an upstream-live service whose platform adapter is required. Until tenant pinning, semantic action policy, cross-client tests, idempotency, and AMOS receipts pass, it is not shown as AMOS-available or tenant-connected, and Desktop never connects directly.
AMOS does not currently claim SOC 2, ISO 27001, HIPAA certification, or another third-party certification unless a current executed report or certificate is provided separately.