Latacora shows why startups need embedded security, not unicorns

At a glance

What this is: This is a conversation about why startups should replace the myth of a single security unicorn with embedded, fractional expertise that spans application security, cloud, incident response, and AI-era security tasks.

Why it matters: It matters because identity and security programmes fail when one person is expected to cover too many disciplines, leaving architecture, incident response, and AI-related exposure under-governed.

Context

Startups often frame security hiring as a search for one person who can cover application security, cloud security, incident response, and team leadership at once. That model breaks because the work spans multiple disciplines that are needed at different moments, and the article argues that the real requirement is not a mythical generalist but durable expertise embedded in the company.

For identity and security teams, the governance problem is not only coverage but timing. The article shows why architectural decisions made early can create lasting exposure, while fractional security support can influence design before weak assumptions become recurring operational work.

Key questions

Q: How should startups structure security coverage before hiring a full team?

A: Startups should divide security into distinct capability areas, then decide which ones need continuous ownership and which can be covered by embedded specialists. The key is to avoid assuming one generalist can hold every domain at once. A workable model gives the company access to depth when needed, while preserving clear accountability for architecture, incident response, and identity governance.

Q: Why do early architecture decisions create so much security debt?

A: Because a small design choice can define the attack surface for years. If a system is built in a way that rules out safer patterns or creates recurring vulnerability classes, teams spend far more effort chasing symptoms than removing the condition that produces them.

Q: What is the difference between reactive security work and embedded security?

A: Reactive security closes issues after they appear. Embedded security participates before implementation is locked, which lets the team shape architecture, reduce attack surface, and prevent recurring classes of defects instead of repeatedly fixing the same kind of problem after release.

Q: How should teams govern AI systems that query identity and incident tools?

A: Teams should treat those integrations as part of the control surface, not just a convenience feature. Access should be least-privilege, auditable, and limited to approved investigative queries. Governance also needs to cover what the AI can see, what it can do, and how its reasoning is preserved for review.

Technical breakdown

Why the first security hire model breaks down

A startup security function is not one discipline, and the article makes that clear by grouping cryptography, Kubernetes, AWS CloudTrail, and incident response as distinct capabilities. The technical problem is coverage fragmentation: each area has different tooling, failure modes, and review cycles. A single generalist can coordinate them, but cannot realistically hold deep fluency in all of them at once. That matters because security decisions are often made at architecture time, not during incidents, and shallow coverage turns design choices into long-lived risk.

Practical implication: map security work to specialisations and stop assuming one person can own every control domain.

How embedded security changes architecture decisions

The article’s strongest technical point is that the most valuable security work happens before bugs exist. One example described a design choice that eliminated the possibility of a user-generated content domain, which then avoided an ongoing cross-site scripting burden. That is architectural security, meaning the team changes system shape so whole classes of vulnerability never appear. This is different from finding and fixing individual defects after release, because the latter treats symptoms while the former removes the condition that produces repeated weakness.

Practical implication: involve security at design time for domain boundaries, tenancy, and content flow decisions that create durable attack surface.

How AI makes internal security tooling more usable

The article also shows how large language models changed the usability of Latacora’s internal security data. Systems that once required specialised query language and scripting can now be accessed in natural language across cloud and identity data sources such as AWS, GitHub, and Okta. The technical shift is not that the underlying data suddenly became simpler, but that access to it became broader and faster. That increases the speed of investigation, but it also raises the need for tighter governance over what data the queries can expose and who can use them.

Practical implication: treat natural-language access to security telemetry as a governed interface, not just a productivity feature.

NHI Mgmt Group analysis

Embedded security is a governance model, not a staffing compromise. The article shows that startups rarely need a single security generalist who can do everything. They need an operating model that combines a primary security owner with specialist depth on demand, because application security, cloud security, incident response, and identity work do not collapse into one role. For practitioners, the lesson is that security capability should be designed as a service model, not as a heroic hire.

Architecture choices made early create the longest-lived security debt. Latacora’s example of a design decision that removed an entire content pattern, but left years of cross-site scripting chasing, illustrates a familiar failure mode: a small upstream decision can create a permanent downstream control burden. This is the kind of problem that only embedded security catches consistently, because it appears before there is anything to remediate. The practitioner conclusion is that design review must be treated as a first-class security control.

AI is widening access to security insight, but also widening the governance surface. The article describes natural-language querying over cloud and identity telemetry as a usability breakthrough. That is useful, but it also means security data is now easier to interrogate by non-specialists, which changes expectations around access control, auditability, and sensitive context. The practical conclusion is that AI-assisted security operations need explicit governance boundaries, not informal trust in the interface.

Security programmes now need three parallel tracks: product AI, employee AI use, and attacker AI. The article’s framing of AI of the company, AI for the company, and AI against the company is a useful way to stop treating AI risk as one bucket. Each track implies different controls, different monitoring, and different escalation paths. The practitioner takeaway is to separate internal AI enablement from external threat adaptation instead of managing both under one generic AI policy.

Early security leadership should be measured by avoided architecture, not by ticket volume. If security only appears after defects are already shipping, the function becomes a backlog service. The stronger model is to measure whether security input changed the system shape, the exposure surface, or the operating assumptions before problems hardened. That is the difference between a support function and a governance function, and it is where embedded security creates durable value.

What this signals

Embedded security changes the control point from remediation to design. Once a team can intervene before the architecture is fixed, the programme stops relying on post-release defect hunting as its main security mechanism. That shifts security from a ticket queue into a decision control function.

AI-assisted investigation will pressure identity and cloud governance to catch up. Natural-language access to security telemetry lowers the barrier to analysis, which is useful for experts and non-experts alike. The governance question becomes who can ask what, against which datasets, and with what logging and review.

Startup security programmes should be built around coverage gaps, not headcount ideals. The practical test is whether the programme can still cover application security, cloud, incident response, and identity when no single hire can credibly own all four. That is the real maturity question.

For practitioners

• Define security coverage by specialism Map application security, cloud security, incident response, and identity/security operations to named owners instead of assuming one first hire can span them all.
• Embed security in design review Require security participation before architecture decisions are final, especially where the choice can eliminate an entire class of vulnerability or exposure.
• Build a specialist on-call bench Create a clear escalation path to deep expertise for cryptography, cloud telemetry, and incident handling so the core team is not blocked by one generalist.
• Govern AI-assisted security querying Set access rules, logging, and review for natural-language queries over cloud and identity data so convenience does not become uncontrolled visibility.

Key takeaways

• The article argues that startups do not need a mythical all-purpose first security hire. They need security coverage that matches the real mix of application, cloud, identity, and incident work.
• The strongest security gains come from architecture choices made early, before defects become recurring operational burdens. That is why embedded expertise matters more than periodic cleanup.
• For practitioners, the lesson is to treat security as a design and governance function, with specialist support available when the problem space changes.

Key terms

• Embedded Security Guidance: Embedded security guidance is inline, context-aware advice delivered inside the developer workflow instead of in separate reports or tickets. It helps developers correct code while they are still working on it. This reduces handoff friction, improves adoption, and makes remediation more actionable at the point of creation.
• Fractional Security: A security operating model where specialist expertise is provided on an ongoing part-time or embedded basis rather than through a single full-time generalist hire. It works best when the organisation needs depth across several domains but cannot yet support separate internal specialists.
• Security Specialisation: A distinct body of security knowledge such as application security, cloud security, incident response, or cryptography. The article’s core point is that these domains are separate enough that one person rarely covers them all well, especially as the environment grows.
• AI-Assisted Security Querying: The use of large language models to interact with security telemetry in natural language instead of specialised query syntax. It broadens access to investigation data, but it also requires clearer governance over permissions, logging, and sensitive context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.