Beginner question: Do I need a dedicated security person to use this?

Your skepticism is completely valid. I've seen teams in your position get tripped up, and it's rarely about the platform's inherent security, it's about the operational overhead they didn't anticipate.

The shared responsibility model does place configuration burdens on you, particularly for access controls and audit log review. Where teams without a dedicated security person often stumble is in maintaining those controls as team roles change. Braintrust's built-in controls can be sufficient for SOC 2, but only if someone actively owns the periodic review of user permissions and ingestion sources. That doesn't need to be a full-time CISO, but it does need to be a defined, recurring task for someone technical on the team.

The time bomb scenario usually happens when that ongoing maintenance is ignored, not when the initial setup is wrong. Can your team commit to a quarterly audit of access logs and integration settings?

Ah, the shared responsibility model. It's a bit like buying a safe and then being told you're responsible for the combination, the alarm system, and who you let into the room. The safe is very secure, technically.

Their controls might be sufficient for a SOC 2 audit, but the auditor will ask *you* for the evidence. That means someone has to produce it. It's not a full time job, but it's a quarterly or monthly "oh right, we have to check the logs and user list" job that inevitably gets de-prioritized until it's a frantic scramble. The ticking time bomb isn't a breach, it's the compliance gap you discover during your own audit.

Great question, and that last line really nails the core anxiety. The ticking time bomb isn't the platform exploding, it's the compliance and permission drift that builds up quietly.

From my tinkering with their access logs and project roles, the burden is definitely on you to map your team's actual needs to their permission sets. The "sufficient for SOC 2" part is true for the *available* controls, but the "genuinely sufficient" part is only true if someone actively shrinks permissions down from the defaults and then revisits it quarterly. Their default project roles are often too permissive for real principle-of-least-privilege use.

So no, you don't need a dedicated security person. You need to task your most paranoid engineer with a recurring calendar invite to audit "who can see what." If that invite gets skipped twice, you're on the path to the time bomb.

Your point about realizing you need a full time person six months in is exactly what to avoid. I've been there with similar platforms, and the answer is a process, not a hire.

The built-in controls are genuinely solid for SOC 2. The time bomb is real, but it's a process bomb, not a technical one. You can defuse it by creating a stupid-simple, 30-minute quarterly checklist for someone on the team (your most detail-oriented backend person is perfect). The checklist is just three things:
- Review the "last login" report and disable accounts for anyone who left.
- Run the project-level permissions report and check if anyone still has "admin" who shouldn't.
- Spot-check the audit log for a key event, like a data source connection, to make sure the trail looks right.

This takes the "ongoing maintenance" and makes it a concrete, small task. The shared responsibility model does mean you're on the hook for your mistakes, but the mistakes here are usually about *inaction* - letting stale access linger - not misconfiguring a complex firewall.

Can you get by without a dedicated security person? Absolutely, if you bake that tiny recurring task into your ops rhythm from day one. Forget to do that, and you'll be scrambling.

Couldn't agree more with the "process, not a hire" angle. That's the entire ball game.

But let's be honest, that "stupid-simple, 30-minute quarterly checklist" never stays that way. You add a new data source next year, the platform updates its permission model, now your spot-check criteria are wrong. The quarterly task quietly becomes a half-day rabbit hole.

So sure, you don't need a security person. You need a process *and* someone who's willing to own the fact that the process will need updating when the vendor changes something. Good luck getting that in the budget.

You've really put your finger on the crucial failure point: the process owner has to care enough to maintain the process itself when things change. That's the hidden, unbudgeted role.

In my experience, that ownership only sticks if it's tied to something the team already values, like sprint retrospectives or release cycles. You bake the quarterly check into the *existing* ritual, and the update cadence for the checklist becomes part of that same conversation. It doesn't magically solve the budget problem, but it anchors the task to a real workflow instead of a floating, forgotten calendar invite.

Otherwise, you're right, it becomes technical debt in process form, and that's often harder to sell.

Totally get where you're coming from. Your question about the ticking time bomb is the right one to ask.

I'd push back slightly on the "full-time person" fear, though. The key is making the ongoing work visible. We treat it like a small, recurring product health metric. It's not a dedicated role, it's a task that rotates among two or three of us who touch the platform most.

That said, your "on the hook for your own mistakes" point is spot-on. The main burden is ensuring your team's workflow doesn't create blind spots. For instance, if you automate data ingestion, you have to own the review of that service account's permissions. The platform won't flag that for you.

It's manageable without a security hire, but only if you accept it as a permanent, lightweight operational tax.