The ForgeThe Forgeby HustleForge
Integration security

An integration is not complete unless it can be observed, governed, and repaired.

Every connection carries documented credentials, permissions, mappings, sync direction, retry rules, and failure handling. Integrations are managed as infrastructure, not as marketing checkboxes.

The Forge is currently in a limited beta. This page describes the controls we implement per-integration; it does not claim third-party compliance certifications we have not undergone. Ask us directly about the specific control you need — we’ll answer honestly.

Controls

Six areas of practice applied to every connection.

Authentication, encryption, permissions, audit, revocation, and ownership — configured per integration, documented per connector, and reviewed at each launch.

Authentication

Standards-first identity

  • OAuth wherever the provider supports it. No stored plaintext passwords.
  • Scoped API tokens with least-privilege access to the specific objects required.
  • Signed webhooks are required where the provider supports them.
  • Credential expiration is tracked and surfaced before the outage window.
  • Rotation is a first-class action on every connection.

Encryption

In transit and at rest

  • All external calls are TLS. Non-TLS providers are declined at assessment.
  • Stored credentials are encrypted at rest with per-tenant boundaries.
  • Card data is never stored — only processor-issued tokens.
  • Sensitive fields (SSN, bank routing, protected health records) are not read unless the specific integration scope contractually requires it.

Permissions

Least privilege, per-role

  • Connecting a system does not grant every employee access to what it holds.
  • Access to synchronized information respects business entity, location, department, role, record ownership, data sensitivity, and action authority.
  • Human approval is available on sensitive outbound writes (refunds, payroll batches, cancellations).
  • Environment separation between sandbox and production is required for validated connectors.

Audit

Observable, replayable, revocable

  • Every synchronization is recorded with timestamp, direction, actor, and outcome.
  • Failed writes carry a specific reason and are assigned for review — no silent drops.
  • Duplicate-event protection is enforced with idempotency keys.
  • The audit trail links source and destination identifiers so nothing is untraceable.

Revocation

The customer stays in control

  • Any connection is revocable by the customer at any time.
  • Revocation stops outbound writes immediately.
  • Inbound data respects the source system's own access controls once the connection is severed.
  • No hidden background jobs remain after revocation.

Ownership

Your data leaves with you

  • Records synchronized into The Forge are exportable at any time.
  • Retention is set by the customer, subject to the source system's own policies.
  • Deletion in the source system is respected inside The Forge.
  • No integration ships with a lock-in clause disguised as an export fee.
Direct answers

The questions IT actually asks before a connection ships.

No hedging. If we don't do something, we say so. If it's beta, we say that too.

What permissions does this integration require?

The minimum object scopes needed for the specific workflow. Broader scopes are not requested even if the provider offers them. Every scope is documented before the connection is enabled.

Can the connection be revoked?

Yes — at any time, by the customer. Outbound writes stop immediately. Inbound data respects the source system's own access controls once the connection is severed.

Which employees can see synchronized information?

Only those permitted by the customer's role, department, entity, and location settings. Connecting a system does not automatically grant every user access to what it holds.

Are outbound actions automatic or approval-gated?

Configurable per action. Sensitive writes — refunds, payroll batches, cancellations — can require explicit human approval; low-risk writes proceed automatically.

Is every synchronization recorded?

Yes. Every sync event carries timestamp, direction, actor, and outcome. Failed events carry a specific reason.

What happens when a credential expires?

The Forge detects the rejected request on the first 401 / 403, pauses unsafe writes, and notifies the technical owner with the specific credential and provider. Pending actions are preserved until re-authorization is confirmed.

Can imported records be exported?

Yes. Records synchronized into The Forge are exportable at any time. Deletion in the source system is respected inside The Forge.

How are duplicate events prevented?

Idempotency keys and provider-supplied event identifiers are used to detect and drop duplicate deliveries — a retried webhook does not create a second record.

Who owns the connected data?

The customer. The Forge processes synchronized data on the customer's behalf and does not resell or repurpose it.

Which third parties process the information?

Only the third-party providers you explicitly connect, plus the infrastructure providers The Forge runs on. The provider list is documented and updated when it changes.

On unsupported compliance claims

The Forge does not currently carry SOC 2, HIPAA, or PCI audit certifications. Where a specific customer engagement requires those, we scope the gap explicitly during the Blueprint. We would rather turn down work than misrepresent the posture.

Ask the specific question. We’ll answer specifically.

IT and technical administrators get a direct security review during the Blueprint — including the credential, scope, retry, failure, and ownership model for each proposed connection.