API key breach on a shipped car-deal agent

Interview metadata

Block 1 — Context

Consequential systems they named

• Black Book API (trade valuation)
• Inventory provider hosted link
• Drive Centric CRM
• Manufacturer incentive systems
• Banking rate systems
• Cloudflare Workers KV storage
• Customer PII collection system

Their language for “agent”

Used “AI agent,” “chatbot,” and “negotiating chatbot” interchangeably. Described it as “an agentic system that works with different sales data, different trade data, different APIs, and basically can provide valuable sales related information back to the customers.” Emphasized the negotiation capability: “We are just trying to create a bot to negotiate. It can negotiate a full car deal.”

Block 2 — The trigger event

What happened

“I think someone accessed the API key. Luckily, I have a limit set. So it locked.” The security breach occurred through their Anthropic console, causing unexpected API usage that triggered their spending limits. Dani discovered the breach through session logging: “when I saw the access, I noticed that it wasn’t even any of the agents that I utilized within the chat. So I’m like, okay. It’s definitely a third person. I don’t know how they got access to it.”

Named owner(s) of “what an agent is allowed to do”

• Dani Dimacale — technical owner; builds and secures the system
• Matt Greenblatt — provides business rules and sales training requirements

Security / compliance / risk conversation

The API key breach forced immediate security discussions. Dani implemented session ID requirements and rotated keys: “I set it up to require a session ID before it can do anything. So it has to start logging that.” They’re actively investigating the security gap but haven’t identified the exact vector: “I’m wondering about some of the non system avenues there would have been for this thing to leak out somehow.”

Block 3 — What they tried

Systems the agent touches (or would need to touch)

• Black Book API for trade valuations (currently integrated)
• Inventory provider hosted link (currently integrated)
• Drive Centric CRM (planned integration for lead sending via ADF format email)
• Manufacturer incentive systems (manual input currently, seeking API access)
• Banking rate systems for financing (planned integration)
• Customer PII storage system

Vendors / tools evaluated and rejected

Built custom solution using Claude API and Cloudflare Workers rather than evaluating existing agent platforms. No specific vendor rejections mentioned.

Customer-operated vs SaaS preference

Strong preference for customer-operated deployment. Built entirely on Cloudflare infrastructure they control, with encrypted secrets stored in Cloudflare Workers KV.

Credential flow / approval surface

All API keys stored as encrypted secrets in Cloudflare Workers. Access limited to Matt and Dani through email-based authentication with 24-hour expiration. No formal approval workflow for agent actions.

Their own connector / integration layer

Built custom integration layer using Cloudflare Workers as the orchestration engine, with KV storage for caching inventory data and rules to avoid over-pulling APIs.

Block 4 — The pitch test

Reaction shape

Strong positive reaction to the deterministic execution concept — agreed with the framing that hard parameters and absolutes need to live outside the LLM. Showed immediate understanding of the context drift problem: “I run into that a lot, too. Even when I teach it something, it does the same thing.”

Of the four dimensions, ranked

1. Deterministic execution — “That’s what I’m concerned about… it’s going to do stuff. It’s going to imagine stuff. It’s going to not follow these rules, which is a problem”
2. Gated approvals — interested in workflow handoffs: “I’m just thinking of how it’s set up now, how that product, how would I pass it off and then it could come back”
3. Action-level audit — already implementing logging but recognized gaps
4. Shared skills across teams — less immediate concern

Their one-sentence pitch to their VP

Did not compose a specific one-sentence pitch, but expressed interest in the security and deterministic execution value proposition.

Block 5 — Budget & authority

Named buyer

Matt Greenblatt appears to be the business decision maker, with Dani Dimacale as the technical implementer.

Proposed next step

Did not propose a specific next step, but expressed openness to continued conversation and guidance on security implementation.

Budget signal

Not discussed explicitly, though they mentioned this is a side project alongside their normal jobs, suggesting limited current budget allocation.

Verbatim quotes

“We are just trying to create a bot to negotiate. It can negotiate a full car deal.” — Block 1

“I think someone accessed the API key. Luckily, I have a limit set. So it locked.” — Block 2

“I run into that a lot, too. Even when I teach it something, it does the same thing.” — Block 4

“I’m just thinking of how it’s set up now, how that product, how would I pass it off and then it could come back.” — Block 4

Action items

• Follow up on security architecture recommendations for preventing API key exposure
• Provide guidance on implementing deterministic tools for deal approval logic
• Evaluate as strong design partner candidate — actively building agents on consequential systems with real security concerns
• Consider technical deep-dive session with Dani on MCP integration patterns