What access does an integrator actually need to our systems, and how do we limit it?
A dedicated account in each system, owned by your company, scoped to the specific objects being read or written, and revocable without breaking anyone else. Never a personal login. Never administrator because it is faster to set up. If a provider cannot name the specific permissions they need and why, they have not scoped the work yet.
Rules that hold across every platform
- A dedicated service account per system, on your domain. Named for the integration, not for a person.
- Least privilege, written down. The specific objects and operations, with a one-line reason for each.
- Read before write. Grant write scope only for the fields in the agreed mapping document, and only after read-only has been running.
- You hold recovery. Your domain, your multi-factor device or shared vault, your billing.
- Reviewed on a schedule. Access granted for a project that ended three years ago is the most common finding in any audit.
Why personal logins fail predictably
Integrations built on an employee's or a contractor's personal account break when that person leaves, break when multi-factor prompts start appearing on a phone nobody is holding, and make your audit log useless because every automated action is attributed to a human who was asleep.
They also make offboarding a choice between a security risk and an outage, which is a choice no one should have to make on a Friday afternoon.
Practice the revocation
The test of an access model is whether you can cut it off deliberately. Pick a non-critical integration credential and revoke it. You should be able to state within minutes what stopped, see an alert confirming it, and restore it just as quickly.
If nobody knows what a credential is used for, that is the answer to your security question. Maintaining a current inventory - system, account, scope, owner, purpose - is unglamorous and it is the document you will want during any diligence, insurance review or vendor transition. It is part of what makes an integration layer genuinely yours.
Recordings and customer data need a separate conversation
Access to call recordings, customer contact information and payment-adjacent records carries obligations beyond ordinary system access. Requirements around recording consent, notification, retention periods and handling of personal information vary meaningfully by state and by the nature of the data, and they change.
Treat these as decisions to make with your own counsel rather than settling them inside a technical scoping call. Practically, that means agreeing in advance what data leaves your systems, where it is stored, how long it is kept, and who can view it - and writing that into the agreement. We build to whatever retention and access constraints a client's counsel sets; see how call data is handled for the technical side of that.
Topics: security · permissions · credentials · governance
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.