DEV Community: Beatriz Albernaz

Your AI agents are probably over-privileged and under-monitored

Beatriz Albernaz — Fri, 29 May 2026 10:13:25 +0000

You've got an AI agent running in production. It has an API key for your database, OAuth tokens for your cloud provider, and access to your customers' data across multiple tenants.

When did you last rotate those credentials?

If the answer is "when we set it up," you're not alone, but you've got a real exposure on your hands.

Why human IAM patterns break for AI agents

Most teams I see apply the same identity model to AI agents that they use for human users. It doesn't hold up.

Human users log in, do a thing, log out. Sessions are bounded. Permissions map to job roles. Rotation happens on a schedule everyone tolerates.

AI agents are different in every one of those dimensions:

They run continuously, not in discrete sessions
They need permissions that change based on task context, not a static role
They generate and consume credentials programmatically, without human review
They operate across multiple customer tenants in the same workflow
A compromised agent credential doesn't just expose data, it takes actions on that data

The blast radius isn't the same. A leaked human user token is bad. A leaked agent credential that has read-write access to your entire database and can execute tool calls across your environment is worse.

What we actually find in AI red teaming engagements

40–50% of high-severity findings in our AI red teaming assessments are identity-related. These are the patterns that come up most:

Static, long-lived credentials
Agents deployed with API keys that haven't rotated since initial setup. Six months is common. The reasoning is usually "rotation would break things" which is true, and also a sign the credential management wasn't designed for automation.

Over-permissioned tool access
An agent needs to query one table. It has credentials for the entire database. This happens because scoping credentials is tedious to do properly, and "it works" is good enough at ship time.

Cross-tenant context leakage
Multi-tenant SaaS products where agent context from one customer bleeds into another customer's thread. Usually a missing tenant ID check somewhere in the tool call chain. Easy to miss in code review, easy to find in adversarial testing.

Secrets in places agents can read them
Environment variables, config files, conversation context. Agents are designed to access these things. An attacker's job is to make your agent hand them over through prompt injection or tool abuse.

What good agent identity looks like

None of this is exotic. It's standard security hygiene adapted for non-human principals.

Short-lived tokens, automated rotation

Credentials for AI agents should expire fast under an hour for anything sensitive. Rotation needs to be automated because you're not doing it manually at that frequency.

# Example: generating short-lived AWS credentials for an agent task
aws sts assume-role \
  --role-arn arn:aws:iam::123456789:role/agent-task-role \
  --role-session-name agent-session-$(date +%s) \
  --duration-seconds 3600

Least privilege, scoped per task

RBAC is too coarse for agents. You want attribute-based or policy-based access control that evaluates context at request time, not a role that's "good enough for most things the agent does."

Define what each agent needs for each task. Grant that. Nothing else.

Inventory your agents

You probably don't have a complete list of which agents are running, what credentials they use, and what they can access. Start there. You can't secure what you haven't inventoried.

A basic agent registry entry per deployment:

Agent name and version
Credentials in use (reference, not value)
Scope of access
Customer tenants it operates in
Last rotation date

Log actions, not just outputs

Your observability stack is probably capturing what the agent says. You also need to capture what it does: which tools it called, which files it read, which APIs it hit, which tenant's data it touched.

This is how you distinguish legitimate agent behavior from a compromised agent doing the same things.

Test tenant isolation explicitly

If you're multi-tenant, add automated tests that verify agents cannot access resources outside their assigned tenant scope. Run these in CI. Don't rely on code review alone, the failure modes are subtle and adversarial testing finds them reliably.

Before your next SOC 2 audit or enterprise deal

Enterprise customers are going to ask about this. Security questionnaires increasingly include questions about AI agent access controls, credential lifecycle, and tenant isolation.

The teams that are ahead of this have:

A separate budget line for agent identity security (not absorbed into AI innovation spend)
Automated credential rotation tied to their deployment pipeline
Fine-grained policies scoped per agent task, not per agent role
Audit logs capturing agent actions with full tenant context
External validation through red teaming before major audits or sales cycles

If you haven't done this work yet, the best time to start is before the questionnaire lands, not after.

We run AI red teaming engagements for B2B SaaS companies building AI-powered features: prompt injection, tool abuse, cross-tenant isolation, credential management. If you want to know what's actually exposed before an attacker does, scope an engagement.

We Built a Pentesting Company Because We Were Tired of Watching Startups Get Burned

Beatriz Albernaz — Wed, 13 May 2026 13:47:03 +0000

There was a pattern we kept seeing that genuinely bothered us.

A startup would get to Series A, or land their first enterprise customer, and suddenly need a pentest report right now. They'd scramble to find a vendor, get hit with a 4-week scoping call process, a €30k quote, and a PDF that mostly described low-severity findings their scanner already caught.

They didn't need a €30k PDF. They needed someone to actually look at their auth layer, their API, their trust boundaries and tell them what was actually broken.

That frustration is what became Faultline Security.

The problem we were trying to solve

When we started talking to early-stage founders about security, the same themes kept coming up:

"We know we need a pentest but have no idea where to start"
"The quotes we got were either too expensive or too vague"
"We have a SOC 2 audit in 8 weeks — is that enough time?"
"Our enterprise prospect is asking for a pentest report and we've never done one"

None of these are hard problems, conceptually.

We get it! Security is almost always the thing that gets pushed to the next sprint, the next quarter, the next funding round. When you're a small team trying to ship and grow, it's genuinely hard to prioritize. But here's what we keep telling founders: starting early isn't harder, it's actually easier.

When your codebase is smaller, your attack surface is narrower, and your team is close to every decision, building a solid security foundation takes a fraction of the effort it will cost you later. The expensive, painful pentests we kept seeing weren't just a vendor problem, they were the result of years of deferred security work landing all at once. We wanted to help teams get ahead of that.

We wanted to build something different: fixed pricing, a scoping process that takes 24 hours not 2 weeks, and findings that are actually written for engineers who need to fix them — not auditors who need to check a box.

What building this taught us

Founders don't know what they need until you ask the right questions.

The first version of our intake process asked things like "what environments are in scope?" and got blank stares. We rewrote it to ask "what would hurt the most if a competitor got in?" That changed everything. Suddenly people could actually answer.

The report is the product.

We spent more time rethinking how findings are written than anything else. A finding that says "Cross-Site Scripting detected on /search" is useless. A finding that shows the exact payload, the session token that was exfiltrated in the proof of concept, and the two-line code fix — that is a product.

Timelines are the most anxiety-producing part of the whole process.

The question we get asked more than any other is: how long is this actually going to take? People have compliance deadlines, fundraise timelines, sales deals on the line. They need a real answer, not "it depends."

We wrote a detailed breakdown of this recently: How Long Does a Startup Pentest Take? — the short answer is 3 to 10 days of active testing plus 2 days for the report, so most teams have something in hand in under two weeks. But the full picture is more nuanced, and worth reading if you're scoping something with a hard deadline.

The parts nobody tells you about starting a security company

Building in security is weird. You're asking people to trust you with access to their most sensitive systems, before they know you well. Trust-building is the entire job before any actual testing happens.

We also learned that pricing transparency is itself a differentiator. Most pentesting firms won't put a number on their website. Scope varies, complexity varies. But the endless "contact us for pricing" dance adds friction that small teams don't have time for. Showing a real range upfront, even approximate, changes the quality of conversations you have.

And the writing matters more than we expected. Content like the timeline post above has brought in more qualified leads than any cold outreach we've done. People who are googling "how long does a pentest take" are in the buying process. Meeting them where they are with an honest, detailed answer builds more trust than any sales email.

Where we stand now

Faultline is purpose-built for SaaS companies and startups that are hitting real security milestones — first enterprise customer, SOC 2 audit, Series A. We're not trying to compete with the big firms doing 6-month red team engagements for banks. We're trying to be the best option for a 20-person company that ships fast and needs a pentest that matches their pace.

If you're building something and wondering whether you need a pentest, when to do it, or how to think about scope we're happy to talk. No sales process. Just people who care about shipping secure software.

You can also scope an engagement directly and get a fixed-price proposal within 24 hours.

What questions do you have about security at the early stage? Drop them in the comments. we read everything.

What pentest does your startup actually need?

Beatriz Albernaz — Thu, 30 Apr 2026 15:02:54 +0000

Most startup founders know they should get a pentest. Fewer know what kind, what scope, or what a reasonable price looks like and the industry hasn't made this easy to figure out.

Pricing is rarely published. Scope conversations happen after you've already given your email to a sales rep. And the word "pentest" gets used to describe everything from a lightweight automated scan to a two-week manual engagement by a team of three.

This guide gives you a framework to self-assess what you actually need, based on where your company is and what you're building.

The variables that actually determine what you need

There are four factors that map pretty cleanly to pentest scope and cost:

1. Company stage
Pre-seed and seed companies usually need a lighter engagement — enough to surface critical vulnerabilities and satisfy early security questionnaires, but not a full-blown compliance audit. Series A and beyond typically have more surface area, more integrations, and investors or enterprise customers who want to see a proper report.

2. What you're building
A web app with an authenticated user section is a different scope than an API serving third-party developers, which is different again from infrastructure with cloud components and CI/CD pipelines. Each surface has different attack vectors and different testing methodologies.

3. Compliance requirements
SOC 2 Type II, ISO 27001, and PCI DSS all have specific pentest requirements. If you're pursuing any of these, the pentest needs to meet certain criteria — scope, methodology, report format — that go beyond a general security assessment. This is often the trigger that moves a startup from "we should probably do this at some point" to "we need this done in the next 90 days."

4. Scope
This is the one founders underestimate most. Scope drives cost more than anything else. A focused test on your main web application is a very different engagement from one that covers the application, your API, your admin panel, your cloud configuration, and your internal tooling.

The main pentest types and when you need them

1. Web application pentest
The most common for early-stage SaaS. Tests your application from the perspective of an authenticated user, an unauthenticated attacker, and sometimes a privileged user. Covers OWASP Top 10 and beyond — auth flows, access controls, injection points, business logic flaws.
→ When you need it: You have a product with user accounts. A customer asked for a pentest report. You're starting a SOC 2 process.

2. API pentest
Similar to a web application test but focused on your API endpoints. Critical if your API is externally facing or consumed by third-party developers. Auth, rate limiting, data exposure, BOLA/IDOR vulnerabilities.
→ When you need it: Your API is your product or a significant part of it. You have developer customers. You're building in a regulated space.

3. Cloud / infrastructure pentest
Tests your cloud environment — misconfigurations, overly permissive IAM roles, exposed storage buckets, network segmentation issues. Usually AWS, GCP, or Azure.
→ When you need it: You've scaled beyond a simple Heroku deploy. You have infrastructure engineers managing cloud resources. ISO 27001 or SOC 2 is on the roadmap.

4. Combined / full-scope engagement
All of the above, sometimes with internal network or social engineering components. More common at Series B+ or when enterprise contracts require it.
→ When you need it: You're selling to enterprise. Your compliance framework requires broad scope. You've had a security incident and want comprehensive coverage.

A quick self-assessment
Answer these honestly and you'll have a good starting point:

-Stage: Are you pre-product-market-fit, or do you have paying customers and scaling infrastructure?

Surface area: What are the components you're worried about? Web app only? API too? Cloud infra?
Driver: Is this proactive, or is a customer / investor / compliance requirement pushing you to do it now?
Timeline: Do you have a deadline (audit, enterprise deal, fundraise)?
Budget range: Are you looking for something under €5k, €5–15k, or are you budgeting for a larger engagement?

The combination of these five answers will tell you whether you need a focused lightweight test, a standard web + API engagement, or a more comprehensive scope.

Skip the guesswork
We built a 5-question quiz that maps your answers to a recommended tier and a starting price.
→ Takes under a minute.

faultlinesec.com/quiz

It asks for your work email before showing the result [full transparency on that] and you'll hear from us. But the recommendation is genuine and accurate enough to use as a starting point for any vendor you end up going with, not just us.