What the connector can and cannot do

Proxara Connect retrieves under one consent and acts under another. The consent an administrator grants to start is delegated and read-only: ten permissions, reads of mail, calendar, Teams messages, OneDrive and SharePoint files and tasks alongside the ordinary sign-in permissions, every read carrying the signed-in employee's own credential. Two independent guards hold that boundary. The infrastructure definition refuses to build an environment whose permission list is not a subset of the reviewed ten, and the setup runner fails the run if the environment it has just built reports any other set.

Acting in those same systems, drafting a reply or creating a task, runs under a separate consent the firm grants the same way, so a read approval never quietly becomes a write approval. It is the same sentence Proxara Connect for IT gives whoever approves the consent.

The model proposes, Proxara executes

The model never reaches a system itself. What it returns is a typed proposal: one action drawn from a closed vocabulary, with its targets, the sources it rests on, and the conditions it expects to hold. Free text is never an instruction to execute, and a proposal naming an action outside that vocabulary, or failing its schema, is rejected before anything is authorized.

Bound to what the work already retrieved

Every target in a proposal is a stand-in this piece of work already owns, and every citation binds a frozen record of what was read, at the version it was read. A target that resolves to nothing, a source that has moved since, and an evidence set that came back incomplete are each a stated reason to refuse a proposal rather than run it. That is what stops an instruction planted in a retrieved message aiming the work at a client, a recipient, or a record that was never in the evidence set.

Nothing in a proposal carries a client identity, because the model worked on stand-ins throughout. What the model sees covers that.

The lane the firm's rules put it in

Firm policy, not the model, decides what happens to each proposed action. It runs automatically, it waits for one named approver, it waits for two distinct approvers, or it is prohibited outright. An approval is bound to the resolved target and the authority behind it, so if either changes the approval no longer holds and the action stops.

Checked again at the moment it commits

Authorization is not decided once at the start. At the write boundary Proxara re-checks the employee's own permission, the current policy version, the stand-in binding, the state of the source, and the provider authority for that exact action before it commits. It then reads the result back from the system it changed, so what is recorded is what happened rather than what was attempted.

Microsoft 365 is the system actions run against. Each action requires a pinned, proven descriptor for that provider; where one is not enabled the action is refused rather than attempted.

What the record holds

Every request and its analysis, each proposal with the reason it was refused or allowed, each approval and who gave it, each execution with what the system reported afterwards, and each time the private view is opened, land on the firm's signed record. It carries counts, categories, states and references rather than client content or client names.