Workspace boundary
Who can read or act
- Account data
- Scoped through the current membership
- Client access
- Limited to explicitly granted businesses
- Ownership
- The last owner cannot be removed or demoted
Trust and control
Powerful enough to write.
Careful enough to stop.
Netrix reaches live customer sites, agency credentials, and client data. The control model treats refusal, exact scope, verification, and recovery as product behavior—not implementation trivia.
Tenant-scoped access
Encrypted credentials
Explicit approval
Reversible writes
NetrixDecision boundary
ReviewPerson decides
TargetExact identity
VerifyRead it back
RevertKnown prior value
Safeguards by boundary
Controls belong where the risk enters.
A broad promise like “secure” says little. These are the concrete boundaries the application enforces.
IDENTITY
Credential boundary
What a connector may use
- At rest
- Integration credentials are encrypted
- At render
- Stored secrets remain write-only in the UI
- At use
- Provider and account scope travel together
Network boundary
Where the server may reach
- Addresses
- Private and metadata targets are refused
- Redirects
- Every hop is validated again
- Requests
- Time and response-size budgets are bounded
Write boundary
What changes on a site
- Approval
- Accepted work is distinct from a draft
- Target
- The page element carries an exact identity
- Outcome
- Applied, verified, failed, and reverted stay distinct
A live change as a transaction
The safe path has more than a Deploy button.
Each phase answers a different question, and a failure in one does not get mislabeled as success in another.
- 01
Resolve
Name the page and exact element the finding belongs to.
Stops on ambiguity - 02
Authorize
Check the acting membership, review state, connector, and site.
Stops on scope - 03
Apply
Write through the active connector and retain the prior value.
Records the attempt - 04
Verify
Fetch the live page and compare the action semantically.
Separate outcome - 05
Recover
Revert to the known prior value or release work after a crash.
Durable trail
Product principles
Clear language is part of the control surface.
People approve.
The platform does not describe a recommendation as a live change or promise hands-off autopilot.
Both facts remain visible.
A connector accepting a write and a live page reflecting it are separate events.
Unclear work stops.
An ambiguous target, mismatched provider, exhausted budget, or unavailable dependency should produce an actionable refusal.
Not left to a retry button.
Durable states, retained prior values, serialized reversals, and stale-work recovery make interruption part of the model.
Connector protocols
Trust is scoped to the path doing the work.
The WordPress plugin authenticates signed requests with replay defenses and its own permission gate. Cloudflare resources are adopted only with persisted ownership evidence. Legacy REST credentials stay tied to one verified site.
NETRIX
POST /applytimestamp · nonce · body digest · signatureSITE GATE
- Signature
- Freshness
- Permission
LIVE SITEExact targetKnown prior value retained
Plain answers
Trust questions
Does Netrix make live changes automatically?
No. Netrix finds issues and can draft remedies; a person reviews and accepts the work before a deployment is requested.
Can a client portal user change agency setup?
No. Client access is limited to the businesses granted to that user, and operational actions such as connector management, audit starts, AI spend, and deployment remain with agency staff.
What happens after a connector says a change succeeded?
Netrix records the write as applied, then independently reads the live page. Only that second check can mark the deployment verified.
Can a deployed change be undone?
Supported deployments retain the prior value and expose a serialized revert path, with the reversal recorded in the same deployment history.
See the system in context