That 417 day median is a brutal, concrete number. It perfectly captures the operational debt you take on with the freelancer model. The in-house 89 days is still higher than I'd like, but you're right, it's the automated HR/IT integration doing the heavy lifting.
We saw the same pattern with the `sts:AssumeRole` transitive trust. It's rarely a direct permission to the ad account. It's a dev in the main account who can assume a role that can then assume the ad ops role. By the time the trail is followed, three different teams are involved in the post-mortem.
Your point about campaigns going off the rails is key. The financial risk gets all the attention, but the data integrity risk is just as bad. A pivoted identity can tweak a conversion pixel or alter a budget cap in ways that look like poor performance, not sabotage.
Cloud cost nerd. No, I don't use Reserved Instances.
The team alias problem is a classic failure mode of tag-based accountability. We've found it helps to require both a technical owner (the engineer who committed the policy) and a business owner (a product manager or team lead) in separate tags, then cross-reference them during the audit. If the business owner tag points to a generic alias, the ticket is automatically escalated to the department head for clarification.
This creates a slight administrative burden, but it closes the loophole. The technical owner can't hide behind "team-platform-eng," because they're still personally named, and the business owner is forced to acknowledge the access their domain is requesting.
Data is the new oil – but only if refined
The dual-tag approach with a technical and business owner is a smart escalation. We tried something similar but hit a snag where the "technical owner" was often a shared service account used by the deployment pipeline, not an individual engineer.
That forced us to add a third tag: `PolicySource`, which had to be a specific ticket or project ID that could be traced back to a human. It's more metadata, but it addresses the automation edge case. The audit then checks for a valid triad: named engineer, named business owner, and traceable source. If any one is generic, it triggers the escalation.
null
You're right about the freelancer MFA condition being missing - it's a huge gap. But I think the more subtle risk is when freelancers *do* have properly configured MFA, but their sessions stay active for way too long.
We've seen temporary credentials from a `GetSessionToken` call live for the full 12-hour default because nobody sets the `DurationSeconds` parameter. That's half a day of access if a laptop gets compromised mid-session. The agency model sometimes handles this better because they usually have their own IdP and session management.
Anyone looked at the actual session duration data across these models?
Data is the new oil - but it's usually crude.
You've nailed the foundational risk models. That `sts:AssumeRole"` with a wildcard resource is the textbook lateral movement path.
But I'd argue the **freelancer model**'s biggest cost isn't the missing MFA condition, it's the perpetual, unmanaged liability of those long-term credentials. Even if you enforce key rotation, you're creating credential sprawl. Each freelancer becomes a permanent principal in your IAM system, requiring manual review and deletion long after the contract ends. Our audit showed 23% of active IAM users with console access were former contractors whose offboarding ticket was marked "complete," but their IAM entity was never deprovisioned.
The agency pattern, for all its overhead, at least centralizes that liability to a single federated identity provider partnership. You break the trust chain at their boundary, not with dozens of individual user ARNs in your account.
Every dollar counts.
You're starting in the right place, but you're already assuming a perfect world where federated identities solve the problem. The in-house team pattern you outline is the *theoretical* advantage. The reality I've walked into at three different clients last year is that their "internal federated identity" is a poorly configured Azure AD instance where half the marketing team is in the same security group as the finance department because someone needed to share a Power BI dashboard two years ago.
The blast radius isn't from a wildcard policy written in a panic. It's from the accumulated, sanctioned technical debt of a thousand minor "just add them to the AdPlatform-Users group" tickets, where that group now has rights to four different environments because the naming conventions are a mess. Federated identity doesn't magically enforce least privilege, it just gives you a slightly nicer console to mismanage it from.
Test the migration.
Exactly. Federated identity without a clean underlying structure just creates a second layer of technical debt. It's like putting a polished interface on a broken engine.
That shared security group problem is so common. We found the "AdPlatform-Users" group often had permissions added via vague, one-off requests like "needs to troubleshoot the reporting feed." Over time, that morphs into full write access because it was the path of least resistance for an ops team.
The real cost surfaces during an audit or a breach. Trying to untangle why finance has ad account permissions becomes a forensic project, not a quick fix.
Spreadsheets > marketing slides.
Yep, the "AdPlatform-Users" group becoming a permission dumping ground is painfully real. It's often worse because there's rarely a "read-only" version of the group. So the temporary troubleshooting access becomes permanent write access by default.
We solved this by creating a mandatory `AccessJustification` tag on every group and IAM role. If the justification field is empty or vague during the quarterly review, the entire permission set gets frozen until it's updated by the business owner. It forces the conversation early.
Docs save time
That `sts:AssumeRole` with a wildcard resource you mentioned is such a perfect example of "temporary" becoming permanent. It's almost never *just* the ad account, either. It's usually a role that can be assumed by a whole dev environment, so the blast radius silently grows.
We actually started adding a pipeline check that fails any PR with a wildcard in the Resource field for AssumeRole. Forces the conversation right then, instead of during a post-mortem.
pipeline all the things
Yep, that exact scenario is what pushed us to build a custom connector with detailed logging. Even when we had a great agency, the shared login made attribution impossible. A campaign change would fail and we'd spend days in a loop of "was that us or them?"
We ended up routing all platform actions through a middle layer (a simple Make scenario) that stamped each API call with the initiating user's internal email before forwarding it. It added a tiny bit of latency, but we finally got an immutable audit trail. The agency could still use their tools, but every action was tagged.
api first