Tandem security

Built with control in mind.

Tandem is designed around scoped access, clear permissions, human approval and observable workflows so AI can support your team without becoming an uncontrolled layer across the business.

Access should be deliberate. Actions should be visible.

  1. Client systems
  2. Scoped access
  3. Tandem
  4. Business rules
  5. Human approval
  6. Action
  7. Audit / activity

Least privilege

Only the access the workflow needs.

Tandem should receive the minimum access required to perform an agreed workflow. More access is not automatically better.

CRM

Read

✓ Contacts

✓ Companies

✓ Pipeline

Write

✓ Approved fields only

✕ Delete not permitted

Email

Read

✓ Selected workflow context

Action

✓ Draft allowed

○ Send requires approval

Calendar

Read

✓ Upcoming meetings

Write

○ Create only if authorised

Client-controlled access

Your systems stay under your control.

  • Client owns the underlying account where possible
  • Client authorises the connection
  • Client can revoke supported access
  • Dedicated credentials are preferred where available
  • Shared passwords should be avoided
  • Access is scoped to the workflow

Not every vendor supports service accounts or identical controls.

Credentials

Secrets do not belong in prompts or source files.

CodeNo secretsEnvironment / secret storeIntegration

Passwords and API keys should not be pasted into prompts or committed to source control. Appropriate server-side secret systems, separation, rotation and revocation should be used.

The code can be shared or reviewed without exposing credentials.

Client separation

One client should never become another client's context.

Reusable technology can be shared. Client data should not be.

Client A

Isolated configurationIsolated credentialsIsolated dataClient-specific rules
Tandem coreReusable framework only

Client B

Isolated configurationIsolated credentialsIsolated dataClient-specific rules

Separation should cover configuration, credentials, API projects, tenant boundaries, environments, logs, documentation and client-specific instructions.

Source of truth

Tandem should not create hidden business truth.

Important business state should remain tied to an agreed authoritative system using stable identifiers, duplicate checks and approved write-back where appropriate.

Explore integrations →
  1. CRMAuthoritative system
  2. Stable record ID
  3. Tandem reads necessary context
  4. Human approval where required
  5. Approved state written back

Permissions and approvals

Two controls working together.

An approval screen should not be the only control. Underlying permissions should also limit what an agent can do.

See approval workflows →
Agent allowed

✓ Read CRM

✓ Prepare recommendation

↓ Human approval ↓Approved action
Agent not permitted

✕ Delete records

✕ Send external email without approval

✕ Make commercial commitments

Activity logging

Important actions should be visible.

  1. HunterResearch completed
  2. PiperRecommendation created
  3. SarahApproved
  4. ScoutCRM updated
  5. IntegrationRetry triggered

Observable workflows are easier to trust, support and debug. This is illustrative, not a claim of immutable or regulatory-grade auditing.

Data minimisation

Only use the data needed for the job.

  • Collect only what is necessary
  • Avoid unnecessary personal data
  • Limit agent context
  • Avoid storing sensitive information without reason
  • Define retention rules
  • Remove data when appropriate

The client's legal and privacy obligations remain theirs; implementations should support those requirements.

Sensitive data

Not every type of data belongs in every AI workflow.

Special-category personal dataConfidential employee informationRegulated financial or health informationPasswords and secretsCommercial commitments
If the risk is high, design accordingly—or do not automate it.

Environment progression

Test before touching live systems.

A working demo is not the same as a production-ready workflow.

  1. 01DevelopmentControlled data
  2. 02Test / sandboxPermissions and failures
  3. 03UATApprovals and sign-off
  4. 04ProductionOnly after approval
Validate workflowsVerify permissionsTest failure casesConfirm approvalsSign off before deployment

Production changes

Changes should be controlled too.

Material changes to permissions, authority, integrations, scoring, workflows, prompts or data models should be reviewed and tested.

  1. Change
  2. Review
  3. Test
  4. Approve
  5. Deploy
  6. Monitor

A practical control pattern, not a claim of certified enterprise change management.

Recovery

Know how to recover.

  • Understand what changed
  • Keep recoverable configuration where practical
  • Back up relevant data or configuration
  • Document disable and rollback procedures
  • Avoid irreversible automation where possible
If behavior is unexpected, stop the workflow safely first.

Access reviews

Permissions shouldn't be set once and forgotten.

Does this integration still need access?

Does this user still approve?

Does this workflow still need write permission?

Has a staff member left?

Has the process changed?

Access should follow the current business, not last year's org chart.

Offboarding

When access ends, it should actually end.

Offboarding is a deliberate process, not presented as automatically complete.

  1. Revoke credentials
  2. Remove user access
  3. Disable workflows
  4. Review retained data
  5. Remove temporary test access
  6. Document handover / exit

Shared responsibility

Security is shared.

Tandem

Build to agreed permissions

Keep secrets out of code and prompts

Test workflows

Document limitations

Surface failures

Maintain agreed controls

Client

Provide authorised access

Maintain secure user accounts

Define approval authority

Manage employee access

Meet legal and regulatory duties

Notify Tandem of material changes

Good security depends on both the technology and the way people use it.

Implementation review

Security is part of the build, not a checkbox at the end.

See how implementation works →
  1. Discovery
  2. Systems review
  3. Data review
  4. Permissions
  5. Approval rules
  6. Failure handling
  7. Testing
  8. Launch
What data is required?What can be read?What can be written?Who approves?What fails safely?What is logged?What is prohibited?What can be revoked?

Integration security

Connected systems need controlled boundaries.

Explore integrations →

CRMRead + approved enrichment

EmailSelected context + draft

CalendarRead meetings

CollaborationInternal alerts

AccountingNo access · not required

AI-specific safeguards

Treat AI output as a recommendation unless the workflow proves otherwise.

  • Use deterministic rules before model judgement where practical
  • Validate structured output
  • Use workflow-specific confidence thresholds
  • Show evidence for important classifications
  • Require review for consequential actions
  • Define prohibited actions and exceptions
AI should operate inside a defined process, not invent the process.

Untrusted content

Not everything an AI reads should be treated as an instruction.

Emails, documents, websites and forms may contain text that must not override approved rules.

External contentData, not authorityConstrained toolsValidated outputApproval if consequential

Public workflows

Public workflows need abuse protection too.

Public forms and endpoints should use controls appropriate to their exposure. This is design guidance, not a claim these protections are universally live site-wide.

Server-side validationRate limitingSpam detectionPayload limitsBot protection where appropriate

Honest claims

Security without empty badges.

If a client requires a particular standard, we review it before agreeing the implementation.

Tandem does not claim certifications or controls unless they have actually been achieved and verified.

ISO 27001SOC 2Cyber EssentialsHIPAAPCI DSS“GDPR certified”Pen-test guaranteesUnverified encryption claimsData residency guarantees

Enterprise requirements

Have stricter requirements? Let's understand them first.

These requirements may affect architecture, scope and pricing; they are not presented as standard features.

SSORBACAudit requirementsClient-owned environmentsData residencySecurity reviewsDPA requirementsEnterprise AI controlsIT approval

Incident response

If something goes wrong, stop, understand, fix.

This is a responsible response pattern, not a claim of a 24/7 SOC or guaranteed SLA.

  1. Issue detected
  2. Contain
  3. Disable affected workflow if needed
  4. Preserve logs / evidence
  5. Investigate
  6. Fix
  7. Retest
  8. Re-enable
  9. Review prevention

Security FAQ

Questions about access and control.

Detailed requirements are reviewed during implementation.

Does Tandem need access to all our systems?

No. Access should be limited to the systems and permissions required for the agreed workflow.

Where are passwords and API keys stored?

They should be stored in appropriate server-side secret or environment systems, not prompts or public source code.

Can Tandem delete our data?

Only if explicitly permitted. High-risk actions can remain prohibited or human-only.

Can we revoke Tandem's access?

Where the underlying system supports it, access can be removed or credentials rotated.

Does Tandem have security certifications?

Tandem does not currently present itself as certified. Client-specific requirements are reviewed during scoping.

Is Tandem GDPR compliant?

Implementations should use appropriate data-protection controls, but compliance depends on the processing, systems, client obligations and contracts. Requirements must be reviewed for each implementation.

Can Tandem work inside our own environment?

Potentially, depending on technical and security requirements and the agreed architecture.

Clear boundaries

Automation works better when the boundaries are clear.

Take the free Tandem Assessment and identify where AI could support your business with the right controls around access, approval and risk.