Least-privilege access
Current operating principle
Systems should receive only the access required for a defined responsibility and operating boundary.
Security and governance
Trust starts with knowing which system is allowed to do what.
Matar’s security model begins with explicit authority, least privilege, human approval boundaries, inspectable evidence, and a defined path to pause or reverse execution.
Current operating principleDeployment-dependent
Human approval boundaries
Current operating principle
Consequential actions are assigned explicit approval, delegation, and escalation rules.
Role-based permissions
Deployment-dependent
Roles and permissions are implemented according to the customer system and deployment architecture.
Audit logging
Deployment-dependent
Events, decisions, approvals, exceptions, and evidence requirements are scoped for the workflow.
Data minimization
Current operating principle
Use and retain only the data needed for the defined operational objective.
Secrets management
Current operating principle
Secrets remain server-side or in approved secret stores and are not exposed to browser code.
Environment separation
Deployment-dependent
Development, test, pilot, and production boundaries are defined for the engagement.
Model-provider controls
Current operating principle
Provider choice does not determine permissions, approval rules, or human authority.
Exception handling
Current operating principle
Known failure and ambiguity paths receive owners, evidence requirements, and escalation routes.
Manual override and delegation
Current operating principle
Authorized people can pause, redirect, or delegate bounded execution according to the contract.
Monitoring
Deployment-dependent
Health, cost, performance, and intervention metrics are selected for the deployed workflow.
Incident response principles
Current operating principle
Containment, ownership, evidence preservation, recovery, and customer communication are defined proportionately.
Customer data ownership
Current operating principle
Customer data remains the customer’s; processing rights are limited to the applicable agreement.
Data retention
Deployment-dependent
Retention and deletion periods depend on the workflow, agreement, law, and customer requirements.
Subprocessor transparency
Current operating principle
Only verified service providers are published; planned providers are not presented as active subprocessors.
Deployment isolation
Deployment-dependent
Isolation choices depend on risk, infrastructure, data sensitivity, and the agreed operating model.
Secure connector architecture
Deployment-dependent
Connectors are scoped, authenticated, monitored, and limited to the actions required by the workflow.
Deployment isolation
Options depend on the customer and the workflow.
Architecture, responsibility, access, data location, recovery, and support are agreed for the operation.
an environment we manage
Assessed per engagement
Hosting, access, monitoring, and support boundaries are defined in the applicable deployment plan.
Customer-managed cloud
Deployment-dependent
May be considered where customer infrastructure, security ownership, and operational access are suitable.
Hybrid or private environment
Deployment-dependent
Isolation and connector boundaries are designed around the customer’s systems and data requirements.
On-premises or virtual private cloud
Not generally claimed
Feasibility must be assessed; the public site does not represent this as a standard live option.
Trust documentation
The documentation follows the deployment and agreement.
Qualified clients can review the security documentation, data processing requirements, active subprocessors, and service commitments relevant to their operating boundary.
Security documentation
Available during qualified discovery
Reviewed per engagement
Public structure available
Service level commitments
Defined in the signed agreement
Incident and customer data principles
Customer data ownership
Customer data remains the customer’s. Processing is limited by the service boundary and applicable agreement.
Retention and deletion
Retention and deletion are defined around the data, workflow, law, contract, security need, and customer requirement.
Incident response
Containment, ownership, evidence preservation, recovery, and customer communication are defined proportionately for the deployment.
Subprocessor transparency
Active service providers are documented according to their role in the deployed system.