The risk you inherit from everything you connect to

An integration is a trust relationship

Every interface is a decision to accept data from somewhere and, usually, to hold a way of authenticating to it. Both directions carry risk and they are different risks.

Inbound: whatever arrives has been produced by a system you do not control, configured by people you have not met. Treating it as trusted because it came from a partner is a category error the partner is trustworthy, the message is just a message.

Outbound: holding a credential for another system means a compromise here becomes a compromise there. The platform becomes a concentration of access that did not previously exist anywhere.

Validate inbound data as if it were public input

The fact that a message arrived over a private connection from a known partner says something about its origin and nothing about its contents. A misconfigured upstream system sends malformed data with entirely good intentions.

So inbound messages are validated structurally and rejected clearly rather than coerced into something that parses. This is the same discipline as the integration work generally, and it happens to be the security control as well.

Least privilege is an integration requirement

The default offer from an integrating system is frequently a broad account, because that is easiest for whoever is setting it up. Accepting it is how a read-only feed ends up with write access to everything.

So we ask for the narrowest credential that does the job, and we ask early, while the other side is still configuring rather than after they have finished. Scope reduction requested six months later is a change request; requested during setup it is just how it gets set up.

Where the platform holds those credentials, they are encrypted with AES-256-GCM as described on our security pages, with the authentication tag verified on every decrypt.

Ask what a compromise here would reach

The useful exercise is not 'could this be breached' assume yes but 'what would the holder of this credential be able to do'. That question tends to produce different architecture.

Credentials scoped per integration rather than shared. Separation between the system that holds a credential and the system that uses it. And clear knowledge of which integrations could be disabled quickly if one had to be.

Rotation has to be routine, not heroic

A credential that has never been rotated is a credential nobody knows how to rotate. The first attempt will be during an incident, which is the worst possible time to discover that three undocumented things depend on it.

So the ability to rotate is designed in, and the stored format carries a version marker precisely so that a scheme can be changed without a flag day.

You are somebody else's third party

The same reasoning applies in reverse, and it is worth sitting with. Every organisation that integrates with us has accepted a share of our risk, and their security review is a reasonable thing to be asked to pass rather than an obstacle.

We would rather have that conversation early and in detail than have it as a late-stage surprise. It is one of the reasons we publish specifics rather than assurances.

It also means keeping our own list current: which integrations exist, what each one can reach, and who owns it on both sides. An inventory that is out of date is not an inventory, and it is usually out of date because nobody was made responsible for it.