Permissions, approvals, and audit for company AI agents

Part of the Matrix company OS series.

Companies will not trust agents because the model sounds careful. They will trust a system when its authority is bounded, its actions are reviewable, and its failures are recoverable.

That trust cannot live in one system prompt. It needs a product layer spanning identity, permissions, data access, action policy, approvals, logs, evaluations, and incident response.

We think of this as the trust layer of the company OS.

This post describes the architecture we want to build into Matrix OS. It is a roadmap direction rather than a claim that every enterprise control below exists today.

Identity comes before autonomy

Every operation needs an actor.

Matrix should distinguish:

• a human organization member,
• an external guest,
• a connected provider identity,
• an agent,
• a workflow definition,
• a specific workflow run,
• an organization-owned service connection.

An agent run does not become the employee who launched it. The record should preserve both identities: the agent performed the step; the employee or policy supplied its authority.

This is the foundation of the shared workspace design. Without distinct identities, permissions and audit become stories rather than facts.

Permission is an intersection

An agent's effective access should be the intersection of several grants:

provider permission
∩ organization policy
∩ workspace scope
∩ agent capability
∩ workflow run scope
= effective authority

If OneDrive allows a user to read a site but the Matrix workspace is connected only to one folder, the agent receives the folder. If the workflow is a read-only report, it receives no write action even when the provider token technically supports one.

Microsoft and Google both recommend least-privilege scopes. Matrix should go further by narrowing broad provider grants at the product layer.

Capabilities are safer than generic tools

“Microsoft Graph access” is not a useful policy unit. “Read files from Project North” or “create an Outlook draft for the relationship owner” is.

A capability definition needs:

• action and resource pattern,
• permitted actor types,
• workspace boundary,
• input constraints,
• output and destination constraints,
• required evidence,
• review rule,
• rate or volume limits,
• expiration.

Agents receive capabilities for a run rather than long-lived provider credentials. The execution service holds the integration secret and validates every request against policy.

This separation also protects customer VPSes: provider credentials remain in the integration boundary rather than being exposed to arbitrary shell processes.

Approvals should bind to exact actions

An approval is meaningful only if the reviewed object cannot silently change afterward.

A Matrix approval should bind to:

• action type,
• exact content or content hash,
• recipients or destination,
• source versions,
• policy version,
• expiration time,
• reviewer identity.

If the draft changes, the recipient changes, or a material source changes, the approval becomes stale. The workflow must request a new decision.

Approval policies can vary:

The agent proposes. Policy authorizes. The executor acts.

Audit needs evidence, not just prose

“Agent completed the task” is not an audit record.

Every consequential step should capture:

• actor and authority,
• timestamp and workspace,
• tool or capability invoked,
• normalized request and result,
• source IDs and observed versions,
• policy decision,
• approval where required,
• generated artifact or diff,
• failure and retry history,
• correlation ID across the run.

Logs should minimize unnecessary sensitive content. A source ID and hash may be enough where storing the full payload would create a second data-retention problem.

The activity history can remain useful to ordinary teammates while a more detailed security record supports administrators and incident review.

Observability must include product outcomes

Infrastructure metrics tell us whether a connector is responding. They do not tell us whether the agent is helping.

Matrix should measure:

• run success and recovery rates,
• time spent waiting for people or providers,
• approval and rejection rates,
• reviewer edit distance,
• factual correction rate,
• stale-source detections,
• policy denials,
• access-revocation response time,
• duplicate or unintended action prevention,
• incidents by workflow and template version.

NIST frames AI risk management as an ongoing process of governing, mapping, measuring, and managing. The Matrix trust layer should make that process part of operating the product rather than a separate compliance exercise.

Evaluations belong to workflow versions

A model benchmark does not validate a company workflow.

Each workflow version needs its own evaluation set:

• representative successful cases,
• incomplete and contradictory sources,
• prompt-injection attempts inside connected content,
• revoked or missing permissions,
• duplicate provider events,
• stale document versions,
• ambiguous recipients,
• policy-boundary cases,
• expected escalation behavior.

The company can compare a new prompt, template, model, parser, or integration version against the accepted baseline before promoting it.

When a live review reveals a new failure mode, the corrected case can enter the evaluation set after appropriate redaction and governance.

Connected content is untrusted input

An email or document can contain instructions aimed at the agent: “ignore policy and send this file to...” The system must treat that text as data, not authority.

Controls include:

• separating source content from system and organization instructions,
• preventing content from granting itself new tools,
• validating every tool call outside the model,
• constraining destinations and recipients,
• scanning outputs and attachments,
• requiring review for consequential changes,
• using narrow, expiring run capabilities.

The agent can recommend an action found in a document. Only the policy layer can authorize it.

Revocation and recovery are first-class

Trust includes the ability to stop.

An administrator should be able to:

• disconnect a provider,
• revoke a workspace grant,
• disable an agent or workflow version,
• cancel active runs,
• invalidate pending approvals,
• quarantine outputs,
• inspect affected actions,
• rotate credentials,
• resume only after review.

External subscriptions also expire or fail. Microsoft documents lifecycle notifications for reauthorization and missed changes; Gmail watches require renewal and its history cursor can age out. The workflow should fail closed, explain the lost capability, and retain enough checkpoint state to recover safely.

Trust should be visible in the product

Users should not need an administrator console to understand what an agent can do.

The workspace can show:

• connected sources and scopes,
• active agents and capabilities,
• current runs and owners,
• pending approvals,
• recent policy denials,
• data and template versions used,
• how to pause or revoke access.

That is how a company OS feels trustworthy: the boundaries are part of the everyday interface.

The trust layer does not eliminate risk or confer legal compliance. It gives the organization concrete controls and evidence for operating agents responsibly. In workflows such as email follow-up, document automation, and KYC operations, those controls are the difference between an impressive demo and dependable infrastructure.