# AI & Agent Security

> Review models, data, tools, memory, identity, permissions, approval gates, and high-impact actions.

Canonical page: https://www.guvenkaya.co/services/ai-agent-security

**Give AI systems useful authority without giving them unchecked access.** We review LLM applications, agents, RAG workflows, and tool integrations to establish what the system can do on its own, and what it should have to ask permission for.

## What we review

- **Instructions & prompts**: System instructions, prompt boundaries, injection paths, and control assumptions.
- **Retrieval & data**: Sources, access, poisoning, sensitive data, provenance, and isolation.
- **Memory & state**: Persistence, cross-user leakage, manipulation, retention, and deletion.
- **Tools & permissions**: APIs, MCP servers, credentials, scope, delegation, and dangerous actions.
- **Identity & approval**: User, agent, service, and human-in-the-loop authorization.
- **Monitoring & response**: Logs, anomaly signals, rollback, containment, and investigation.

## Best used when

- **Sensitive access**: An agent can read sensitive data or call business-critical tools.
- **High-impact action**: Automation can change records, move value, deploy code, or trigger workflows.
- **New trust model**: RAG, memory, MCP, or multi-agent architecture changes authority boundaries.
- **Before expansion**: Leadership needs a bounded view of AI risk before launch or expansion.

## How we review your agent’s permissions and actions.

1. **Build the agent threat model**: Map the tools, data sources, and actions available to the agent. Document who can influence its inputs and where human approval is required.
2. **Trace inputs through to actions**: Follow prompts and retrieved content through data access, tool calls, and approvals. Record the permission and data boundaries each flow must preserve.
3. **Test misuse and write regression tests**: Challenge the agent with prompt injection, unauthorized access, and tool misuse scenarios. Add security tests to your repo and record which controls hold or fail.
4. **Verify controls and document conclusions**: We always verify fixes through retesting, including changes to permissions, approvals, monitoring, and recovery. Tie the principal’s signed opinion to the reviewed commit, permissions, and evidence.

## Deliverables

- **Findings report**: Technical and workflow findings, each with the way it gets abused or fails on its own.
- **Threat model**: Agent access, human approval boundaries, and the results of tested attack scenarios.
- **Record of flows and security properties tested**: Prompt, retrieval, tool call, approval, and the high-impact action at the end, each with the property it has to hold.
- **Invariant register**: Each security property, its test result, and supporting evidence.
- **Security tests in your repo**: Regression tests for agent permissions, data access, and tool use, ready to rerun after fixes and future changes.
- **Signed opinion on a reviewed commit**: The principal’s conclusions, tied to the reviewed commit, permissions, and evidence.

## Engagement team

- **José C. Ramírez**, Specialist Advisor: Smart contract, protocol, application, Rust, EVM, and AI-assisted security analysis.
- **Michal Bajor**, Specialist Advisor: Exchange, funding, custody, API, web application, red-team, and L1 security.
- **Timur Güvenkaya**, Founder & Partner: Rust-based and non-EVM systems, protocol security, architecture, infrastructure, and custody.

## Frequently asked questions

### Do you test prompt injection?

Yes. We test how untrusted instructions can affect retrieval, memory, tool calls, and approvals. The review checks whether those inputs can expose data or trigger actions outside the intended permissions.

### Can you review an application that uses a third-party model?

Yes. The review can cover your application’s instructions, data access, tool integrations, and approval controls. Access to the model provider’s internal systems is a separate scope question; we state any limits on what we can verify.

### What access do you need?

We need to understand the agent’s tools, data sources, identities, permissions, and expected behavior. For a review that includes code, we need access to that code during scoping, alongside architecture documentation, configuration, your main concerns, and your deadline. We also agree access to logs and test accounts for the workflows in scope.

### How do you test agents without executing harmful actions?

We agree the test environment and permitted actions before testing. Test data, restricted credentials, and simulated tools can help isolate sensitive actions. Any production testing needs explicit boundaries and stop conditions.

### Can you check fixes after the review?

Yes. We always provide remediation guidance and verify fixes through retesting. We rerun relevant scenarios and check changes to permissions, approvals, and data access. Regression tests help your engineers repeat those checks as the application changes.

## Related services

- [Secure Code Reviews](https://www.guvenkaya.co/services/secure-code-review.md): Find security flaws in critical code, including authorization, business logic, and state changes.
- [Secure Architecture & Process Design](https://www.guvenkaya.co/services/secure-architecture-process-design.md): Design or assess critical systems, workflows, integrations, and operating controls before implementation or a major change.
- [Risk Assessment](https://www.guvenkaya.co/services/risk-assessment.md): Give leadership a prioritized view of where security risk concentrates and what to address first.

## Map the authority before the agent uses it.

Describe the agent’s tools, data access, and actions. We will define the review or design scope.

Discuss your scope: https://www.guvenkaya.co/contact