Security evaluation package

Scope and status

• It covers event delivery by webhook, the read data API and the events log, described in this documentation.
• Technical facts were verified against the platform code at revision c2ca4e785df8 of api-daas; retention periods and design objectives come from the platform technical design and are marked as such.
• This package does not claim security certifications or third-party audits.
• Contractual terms (service level, sub-processors, data processing, vulnerability disclosure) are in the Complementary Annexes (published in Spanish) and the Privacy Policy; this page cites them and does not replace them.

Architecture and data flow

A business fact (for example, a contract changing status) is captured inside the same transaction of the business database and left in an outbox. A relay copies it into the events log, which lives in a separate database isolated per company. A single process, with no inbound access from the internet, takes the pending deliveries and sends them to the company HTTPS destination. That process is the only one with outbound internet access and the only one holding the private keys that decrypt destination credentials.

Action in Masnet
  -> transactional capture (business database) -> outbox
  -> relay -> events log (isolated database, rows separated per company)
  -> delivery scheduler -> sender process (only one with internet egress)
  -> HTTPS (TLS) -> customer company destination

• Each delivery is projected, at send time, with the field groups the destination has been granted; before every attempt the state of the integration and of the destination and the current permissions are checked again.
• The API pods encrypt a destination credentials only with a public key: a compromised API can create material but cannot read it.
• An integration never administers integrations: its credentials cannot change the configuration.
• The data API is always limited to the company of the credential; the company is never a parameter and a foreign object responds as nonexistent.

Data that leaves, by domain and group

The company grants each integration a permission per domain and per field group. public and business leave when the domain is granted; confidential and people only with explicit confirmation from the administrator. The table counts, per object, the top-level fields of data.object that belong to each group according to the published schemas; a nested object counts as one field.

What is never exported

• Free text of comments, notes, conversations, justifications and internal remarks.
• File contents and signed URLs.
• KIM data, prompts and artificial intelligence answers.
• Personal marks, drafts, checklists and private tasks.
• Secrets and credentials, telemetry and navigation.

The user actions log exports the fact of each action, never its content. Name, email, IP and user agent additionally require the people group, and reading requires the administrator to declare that the company informed its users of the monitoring.

Encryption and signing

Network egress and IP addresses

Masnet does not publish fixed outbound IP addresses. Deliveries leave from addresses shared among companies, so the IP does not authenticate: the receiver must verify the signature or the credential. A receiver whose firewall requires a source IP allowlist uses pull mode (data API and event log), queried from its own network; if a company also requires receiving webhooks from known IP addresses, it is agreed with that company.

• Each attempt resolves the DNS name, rejects any non-public address and pins the connection to the validated addresses.
• Redirects are not followed and the response is read only up to 2 KiB.
• The address of the OAuth authorization server goes through the same defenses.
• The destination URL, which may include a signature in the query, is treated as a credential: it is encrypted, shown masked and not logged.

Retention

Values from the platform technical design:

Events are partitioned by day and deleted by partition. A request to erase personal data purges the affected content. For account data at the end of the contract, see section 9 of the Privacy Policy and Annex F.9 of the Annexes.

Audit

• Token issuance, authentication failures and reads of the events and actions logs are recorded per integration, with the request identifier.
• Ten authentication failures of a client within 15 minutes trigger a notice to the integration administrator. Repeated failures from one IP increase the delay and may block it; per client there is only delay, never blocking, so a third party cannot lock out a legitimate client.
• Configuration changes (destinations, permissions, credentials, declarations) are recorded and can be received as the audit.integration_changed event, which never includes secret values.
• Each delivery keeps its history: attempts, codes, duration and the SHA-256 digest of the body sent, to reconcile with the receiver.

Secrets management

• Signing secrets, API keys and client secrets are shown only once and cannot be read afterwards.
• API keys expire by default after 365 days and each client accepts two active secrets to rotate without interruption; revocation is immediate.
• Receiver response excerpts are sanitized: they do not retain the credentials that were sent to it.

Incident response

Published notification period: section 10 of the Privacy Policy states that, for security incidents affecting personal data, Masnet will assess the risk and notify the Customer or the affected data subjects within 72 hours of confirming the incident. Annex F.7 of the Annexes adds that notification is made without undue delay and with cooperation in the assessment. Vulnerability reports are sent to [email protected]; the responsible disclosure policy is Annex B.

Sub-processors and data processing

• Roles: the customer company is the data controller and Masnet is the processor (Annex F.2).
• Sub-processors: Annex D describes their categories and obligations, and sections 7 and 8 of the Privacy Policy identify the providers and international transfers. Detailed information is provided on request at [email protected] or [email protected].
• Law 21.719: the Privacy Policy describes the regulatory transition. For a detailed Data Processing Addendum, Annex F.10 says to request it from [email protected].
• Design measures of the integrations: minimization by default (people excluded), a record of every delivery, immediate revocation and bounded retention.
• Availability: Annex A sets the monthly availability of the Platform.

External penetration test

The external penetration test prior to general availability has not been performed yet. Its results will be published on this page once it exists.