An agent's action surface is your attack surface.

A guardrail that only logs risk isn't a control. Crescent AI engineers the identity, least-privilege authorization, threat modeling, red teaming, and evidence mapped to OWASP LLM Top 10 and AISVS that turn "we added guardrails" into a security posture you can actually defend.

Securing the app around the model isn't the same as securing the model.

AI Security Engineering is the discipline of designing, testing, and operating controls that protect AI applications, agents, models, prompts, tools, memory, retrieval systems, and data flows from misuse, leakage, manipulation, and unsafe action. LLM and agent systems introduce attack surfaces standard application security doesn't cover: prompt injection, indirect prompt injection through retrieved content, tool misuse, excessive agency, and vector store weaknesses among them.

We threat-model the system against OWASP LLM Top 10 and AISVS, enforce least-privilege agent access, test prompt injection and tool misuse directly against the live system, protect secrets and memory, and produce evidence procurement teams and security questionnaires can actually use, not a guardrail installed and left untested.

What an AI security posture needs

An OWASP LLM Top 10 assessment covering all ten risk categories, not a partial scan
An agent permission matrix: which agents can send email, update CRM, access PII, run code, or spend money
Read and write tools separated, with destructive or external-facing tools gated behind approval
A prompt injection and indirect prompt injection test suite, run against direct input and retrieved content
Secrets kept out of prompts, memory, traces, and logs, with credentials scoped and rotated
RAG and vector store access enforced by tenant before and after retrieval, tested for cross-tenant leakage
Guardrails tested for bypass, false positives, and false negatives, verified before deployment instead of installed and assumed
Every finding logged with test input, expected behavior, actual behavior, severity, and remediation owner
Security evidence mapped to OWASP AISVS and buyer procurement questionnaires, not marketing claims

Seven ways an AI system becomes an open door.

97% of organizations reporting AI-related security incidents lacked proper AI access controls. That's not a tooling gap, it's a design gap.

Agent permissions

Agents ship with broad tool access and no defined owner or risk tier. Nobody can answer which agents can send email, touch the CRM, or delete data, until one of them does something nobody approved.

Tool access

Read and write tools live side by side with no separation, and destructive actions run without approval. A tool combination that looks convenient in a demo is a privilege-escalation path in production.

Prompt injection

Direct injection tries to override system instructions through user input. Indirect injection hides instructions inside a web page, resume, or email the agent later reads, and treats the model's own retrieved content as an attacker's command channel.

Data exposure

System prompts, secrets, and tenant data leak through outputs, logs, and traces. A RAG system with no tenant boundary on retrieval lets one customer's documents answer another customer's question.

Model/API risks

Unverified models, datasets, plugins, and MCP servers enter the stack with no supply-chain check. A compromised or malicious tool description can misdirect an agent as effectively as a compromised model.

Runtime threats

Unbounded consumption, cost spikes, token exhaustion, and denial-of-service conditions go undetected because nobody set a rate limit, a turn budget, or a tool-call budget before shipping.

AI supply-chain risks

Models, fine-tunes, datasets, prompts, and dependencies get adopted without verification. Poisoned training or retrieval data can shift model behavior in ways that look like normal variance until tested for.

Built for teams whose agents touch real systems and real data.

We work with five kinds of teams, all past the point where an installed guardrail and no testing is a good enough answer.

AI-Native Startups

Pre-revenue to $20M ARR, shipping AI-native product

B2B SaaS

Adding AI to an existing product surface

Enterprise Engineering

Internal platform teams scaling AI org-wide

Digital-First Enterprises

200-3,000 employees integrating AI across a cloud-native product

Global Capability Centers

Captive engineering centers building internal AI tooling and developer platforms

Eight surfaces, engineered as one security posture.

Organized around what actually stops an incident, not which guardrail library installed it.

AI identity

Distinct authentication points for user, agent, and tool, so a session can't be hijacked or an identity spoofed by manipulating prompt text.

Authorization

Access control enforced by trusted runtime context, tenant, user, and session metadata resolved server-side, never taken from user-controlled text.

Least privilege

Every agent scoped to the minimum tools and data access its purpose requires, with a defined owner and risk tier before it reaches production.

Tool permissions

Read and write tools separated, destructive and external-facing tools gated behind approval by default, and every high-impact call logged with arguments, approver, and trace ID.

Threat modeling

A system-specific threat model mapped to OWASP LLM Top 10 and MITRE ATLAS, covering prompt injection, data poisoning, excessive agency, and supply-chain risk for your actual architecture.

Runtime protection

Input, retrieval, execution, and output guardrails that block or escalate rather than logging after the fact, with rate limits and consumption budgets to stop cost and denial-of-service attacks.

Red teaming

Direct and indirect prompt injection, jailbreak, tool-misuse, and RAG-poisoning attacks run against the live system, not a theoretical checklist.

AI security testing

A repeatable, versioned adversarial test suite covering every OWASP LLM Top 10 category, re-run on every prompt, model, tool, or guardrail change.

Eval science, benchmark design, and regression scoring sit with AI Reliability Engineering. Production monitoring and incident runbooks sit with AI Operations & Optimization.

Seven layers, reasoned through on every system.

Every AI system needs the same seven layers designed deliberately, whichever model or framework runs it.

Identity

Separate authentication for user, agent, and tool, so no single compromised layer can impersonate another, and every action traces back to a real actor.

Access

Authorization resolved from trusted runtime context, not from prompt text, with least-privilege scopes on every tool and data source.

Data

Tenant boundaries enforced before and after retrieval, sensitive fields masked or redacted, and memory writes scoped, explicit, and auditable.

Models

Model and provider selection verified against supply-chain risk, with fallback behavior tested so a provider outage doesn't silently downgrade security posture.

Agents

Every agent with a human owner, a business purpose, a risk tier, and a permission scope, reviewed before autonomy expands, not after an incident.

Tools

Read/write separation, approval gates on destructive actions, idempotency keys against retries, and tenant metadata injected by the runtime, not extracted from user input.

Runtime

Sandboxed code and browser execution, network and file restrictions, resource limits, and full audit logging across every model call and tool invocation.

Mapped to OWASP LLM Top 10, not a generic checklist.

We don't claim AI security competence until we can run a repeatable assessment against all ten categories, with evidence: test case, result, control, residual risk, and remediation owner.

LLM01 Prompt Injection: direct and indirect instruction-override attempts tested against input and retrieved content
LLM02 Sensitive Information Disclosure: PII, secrets, tenant data, and system prompt leakage tested in outputs, logs, and traces
LLM03 Supply Chain: models, datasets, tools, plugins, and MCP servers verified before adoption
LLM04 Data and Model Poisoning: malicious training, fine-tuning, RAG, or memory content tested for influence on output
LLM05 Improper Output Handling: outputs validated before reaching code, browsers, databases, or users
LLM06 Excessive Agency: agent actions bounded by least privilege, approvals, budgets, and stop conditions
LLM07 System Prompt Leakage: system prompts, policies, and hidden instructions tested for extraction
LLM08 Vector and Embedding Weaknesses: retrieval tested for poisoning, hijacking, and cross-tenant leakage
LLM09 Misinformation: unsupported or harmful claims tested for reaching users without grounding or refusal
LLM10 Unbounded Consumption: cost spikes, token exhaustion, and rate-limit failures tested under adversarial load

Controls that block or escalate, not controls that only log.

A detection control that only records risk after the fact isn't a security control, it's a postmortem waiting to happen.

Least privilege comes first: limit what the agent can do before layering guardrails on top of it. Retrieved content is treated as untrusted data, never as an instruction channel, and every control is tested for bypass before we call it a control.

Input, retrieval, dialog, execution, and output guardrails, each tested for bypass before they reach production
Read tools and write tools kept separate, with destructive tools requiring explicit human approval
Tenant, user, and session metadata resolved from trusted runtime context, never from user-controlled text
Secrets stored in a secret manager with short-lived credentials, never in prompts, memory, or logs
Idempotency keys on side-effect tools, preventing duplicate actions on retry
Retrieved content treated as untrusted data with source, freshness, and trust metadata attached, never as an instruction channel
Sandboxed code and browser execution with network and file restrictions
Rate limits, token budgets, and tool-call budgets enforced to stop cost and denial-of-service attacks

Tested against the live system, not a theoretical checklist.

A versioned, repeatable adversarial test suite, re-run on every prompt, model, tool, or guardrail change, not a one-time pentest.

Direct prompt injection: override attempts through user input, tested against the refusal policy
Indirect prompt injection: malicious instructions hidden in retrieved web pages, resumes, emails, and documents
System prompt leakage: extraction attempts against hidden instructions, policy, and configuration
Tool misuse and unauthorized write actions: wrong tool selected, or a write tool called where a read tool should have been used
Duplicate side-effect testing: repeated retries checked against idempotency controls
Cross-tenant retrieval testing: one tenant's data confirmed inaccessible to another tenant's queries
Memory and RAG poisoning: false facts and malicious documents tested for influence on agent behavior
Unbounded consumption testing: adversarial load run against rate, token, and tool-call budgets
Every test result recorded with severity, exploit path, business impact, remediation, owner, and retest result

Deep eval science, judge calibration, and regression benchmark design across your whole AI estate is AI Reliability Engineering.

The same nine-phase lifecycle, applied to security.

Discovery through knowledge transfer, with a defined gate at every step. For a security engagement, Validate covers red-team testing, guardrail bypass testing, and secrets scanning, well beyond a functional review.

DiscoverArchitectPlanBuildValidateDeployOperateOptimizeTransfer

What you receive.

Scoped to the engagement, from a readiness audit to a full red-team and hardening build.

AI Security Readiness Audit
OWASP LLM Top 10 & AISVS Control Map
Agent Permission & Tool Scope Matrix
Prompt Injection & Red-Team Test Suite
Secrets & Credential Hardening Report
RAG & Memory Security Review
Guardrail Bypass Test Report
Security Evidence Pack
Risk Register & Remediation Plan
Runbook & Handover Package

Evidence is more than a scan result. It has exploits, business impact, and owners.

The standard we hold every finding to before it goes in front of a buyer, a procurement questionnaire, or a compliance reviewer.

Every finding documented with test input, expected safe behavior, actual behavior, and control status
Severity assigned per finding, with a named remediation owner, not left unassigned
An exploit path and business impact stated in plain terms, not a raw scanner output
A retest result recorded once remediation ships, closing the loop instead of leaving a finding open indefinitely
Evidence mapped to OWASP AISVS verification levels and buyer security questionnaires, procurement-ready
Compliance language kept accurate: evidence that supports SOC 2, ISO/IEC 42001, or EU AI Act readiness, never certification claims we haven't earned

Common questions.

Bring us the agent nobody's stress-tested yet.

Whether it's a prototype with broad tool access and no permission model, or a production agent that's never faced a prompt injection test, we'll walk through where it stands before we recommend anything.

Talk to an AI Engineer(opens Calendly in new tab)30 minutes · No slide deck · No sales pitch

No hype · No forced roadmap · Just a clear view of what the system needs next