The Security Audit That Found Zero Shared Passwords

The questionnaire arrived as a spreadsheet attachment with forty-two rows, and one of them stopped the account director cold: "Describe how access to our advertising accounts is controlled, including credential management and the process for granting and revoking access." For most of the agencies this client had ever worked with, that single question was where the conversation got uncomfortable. This is the story of a different outcome. In this agency security audit shared ad account passwords were exactly what the reviewers went looking for to scrutinize — and there were none. The agency passed not on the strength of its policies, but on the shape of its architecture.

This is a composite story drawn from a pattern that is common once agencies start selling to mid-market and enterprise clients. The names and exact details are illustrative; the failure mode — and the architecture that sidesteps it — are real.

The questionnaire: procurement asks who can touch the account

The agency had just won a larger-than-usual client, a funded consumer brand with a real security function. Before the contract could be signed, procurement sent a vendor security questionnaire — the kind of document that used to be reserved for software vendors and now lands on any agency that touches a regulated brand's accounts and data. Buried in it were the questions that decide whether an ad agency looks like a professional partner or a liability: Who on your team can access our ad accounts? How is that access granted? How is it revoked when someone leaves? Are any credentials shared? Is there a record of what your team changed?

The account director's first instinct was the instinct most agency leads have: start drafting careful answers. Describe the password manager. Explain the offboarding checklist. Reassure the reviewer that the team is disciplined. But the agency's operations lead stopped that draft, because she knew something the director did not fully appreciate yet — the honest answers to those questions, given the way the agency actually worked, were not reassuring at all. They were a list of things that could go wrong.

Why most agencies fail this on policy, not architecture

Here is the trap. The standard agency answer to "how is access controlled" is a set of policies layered on top of shared credentials. The agency holds the client's Meta login in a password manager, documents the two-factor seed so more than one person can get past the 2FA prompt, keeps a rule that credentials are not pasted into chat, and maintains an offboarding checklist so that when a buyer leaves, someone remembers to rotate the password.

Every one of those is a promise, and every promise is a place to fail. A password manager is only as safe as the people with access to the entry. A documented 2FA seed defeats the entire point of 2FA the moment it leaves the authenticator. An offboarding checklist works until the one busy week it gets skipped. We have written before about how shared logins quietly kill an agency operationally; a security review is where the same shared logins kill the agency commercially, in front of the client, on paper.

The operations lead had seen agencies lose deals at exactly this step. The reviewer asks for the list of people who know the client's password, the agency produces it, and the conversation turns into a negotiation about rotation schedules and vault permissions — a negotiation the agency can only lose, because the underlying fact never changes: humans are holding the client's credentials.

The architecture answer: a System-User token, no shared logins to audit

The agency answered the access-control question with one paragraph, and the paragraph described architecture instead of policy. The agency does not hold or share the client's Meta login. It connects the client's business once through a System-User token — a server-to-server credential — and from that token the operating layer discovers the connected ad accounts automatically via the business identifier. Media buyers never receive the client's password, because there is no point at which a buyer logs into the client's account with a personal or shared credential. They work through the agency's own internal access layer.

That single architectural choice dissolves the entire category of questions the questionnaire was built to probe. There is no shared password to store, so there is nothing to leak from a vault. There is no documented 2FA seed, so there is no defeated second factor. There is no credential to rotate when a buyer leaves, because no buyer ever held one. The reviewer went looking for the shared-credential risk that every other vendor's answer revealed, and on this agency there was simply nothing to find — not because the agency was careful, but because the risky object did not exist in its workflow. This is the architectural counterpart to the operational point in our guide to separate logins versus a real operating layer: the operating layer is what lets one connection serve many buyers without ever distributing the credential.

Internal RBAC: access granted by role, revocable, scoped, logged

With no shared password to manage, the access question moved to where security teams actually want it: inside the agency's own role-based access control. Each buyer, strategist, and account lead had a named seat with a defined role. Access was granted by assigning a role, scoped so that a role could reach only the accounts and actions it needed, and revoked the instant the seat was removed — no password rotation, no scramble, no dependency on anyone's memory.

This is the structural opposite of the failure modes catalogued in our piece on the permission mistakes agencies make. When access is a shared password, you cannot grant it narrowly, you cannot revoke it cleanly, and you cannot prove who had it. When access is a role on a named seat, all three become trivial. The reviewer asked how a departing employee's access is removed; the answer was "we remove their seat, and their access ends with it" — a sentence that needs no follow-up because there is no shared secret still circulating after they are gone.

The audit trail as evidence: who changed what, when

The questionnaire's last access question was the one agencies dread most: is there a record of what your team changed on our accounts? On shared logins, the honest answer is no — the native histories stamp every change with the same shared owner identity, so there is no way to attribute an edit to a person. This agency's answer was a screen. Because every launch, budget change, pause, and creative edit ran through the operating layer, each one was captured automatically and attributed to the named seat that made it, with a timestamp, across every platform the client ran on.

That audit trail did double duty. For the security review, it answered the change-record question outright: yes, every change is attributed and timestamped, here is the timeline. For the agency's own operations, it was the same accountability record we describe in why ad accounts need a real audit log — the thing that turns "we think someone adjusted the bid" into "this buyer made this change at this time." The reviewer treated a clean, attributed change log as a sign of a mature vendor, because it is one. An agency that can show exactly who did what, when, is an agency that has thought about accountability before being asked.

Passing the review without rewriting a single access policy

The most striking part of the outcome was what the agency did not have to do. It did not write a new access-control policy for the engagement. It did not stand up a special process for this one security-conscious client. It did not promise to rotate credentials more often or restrict who held the vault entry. It answered the questionnaire by describing the way it already worked — the System-User connection, the role-based seats, the attributed change log — and the description was the compliance.

That is the quiet leverage of being secure by architecture rather than by procedure. Procedural security has to be performed, documented, and re-performed for every audit, and it degrades the moment attention lapses. Architectural security is a property of the system that holds whether or not anyone is watching. The agency passed the review in the time it took to write a few paragraphs and share a screenshot of the access layer, because the work of passing had been done years earlier when it chose not to distribute credentials in the first place.

What 'secure by architecture' wins beyond the questionnaire

The signed contract was the obvious prize, but the architecture kept paying after the deal closed. The same setup that satisfied one client's procurement team satisfied the next with no additional work, which meant the agency could pursue security-conscious accounts as a market rather than treating each as a special case. Every future questionnaire met the same prepared answer.

It also changed the agency's internal risk posture. A buyer leaving was a non-event — remove the seat, done — instead of a credential-rotation fire drill across a dozen client accounts. The attributed change log meant internal handoffs came with a complete map of recent changes. And the absence of shared secrets meant the agency's single largest breach surface, a vault full of client logins, simply did not exist to be compromised. The architecture that won the questionnaire was the same one that made the agency harder to damage on any ordinary day, across all six advertising platforms it managed for clients.

The lesson: the strongest security answer is having nothing risky to confess

Asked afterward what made the difference, the operations lead put it plainly: the agency did not pass the security review by being better at managing risky things. It passed by not having the risky things to manage. There was no shared password to protect, no 2FA seed to control, no credential to rotate, because the way buyers reached client accounts never involved any of them.

That is the principle any agency selling to serious clients should absorb. As you move upmarket, the security questionnaire stops being an occasional surprise and becomes a routine gate, and the question it is really asking is always the same: where is the risk in how you handle our account? An agency built on shared logins has to answer that question with a list of mitigations, each one a place it could fail. An agency built on a System-User token, internal role-based access, and an attributed audit trail can answer it with architecture — and the strongest possible answer to "where is the risk" turns out to be the one that has nothing risky to confess. For the rest of the playbook on running an agency this way, see the agency tools hub.