# Derik Callahan > Security leader working where security operations meets AI. Senior Manager, IT Security — Security Engineering & Operations. Phoenix Metro, Arizona. Focus: AI risk & agentic security; Cyber operations & threat management; Zero Trust, identity & SSE modernization. ## About Player-coach security leader with 15 years in IT and cybersecurity, 7 of them managing security teams. I lead security engineering and operations for a publicly traded company. Our 24/7 SOC runs through an MDR partnership at a mean time to detect under 5 minutes and a mean time to respond under 1 hour. We got there through detection engineering and SOAR automation, not added headcount. I rebuilt that SOC around agentic AI. Production agents triage phishing, endpoint, and identity alerts, and an analyst reviews every incident with AI doing the enrichment and investigation legwork. I sit on our AI Center of Excellence and architecture committee and lead safe AI adoption: use-case risk review, AI/MCP gateways, agent runtime guardrails, non-human identity controls, and OpenTelemetry tracing so the SOC can detect and investigate agent misuse. ## What the SOC is measured on - < 5 min mean time to detect - < 20 min triage - < 1 hr mean time to respond ## How I lead - Develop engineers rather than hire around gaps — grew interns into senior analysts and service desk staff into identity engineers. - Set the operating plan and the metrics the program is measured on, and personally drive the critical initiatives and high-severity incidents. - Report risk posture and program performance to senior leadership through KPI/KRI metrics and automated dashboards. - Drive remediation through influence — partner with engineering and application owners so findings actually get fixed. - Manage MDR, testing-firm, and platform vendor relationships against outcomes, not activity. ## Projects - **HackerOne MCP server**: An MCP server covering the full HackerOne REST API (Customer and Hacker, 174 tools), over stdio or hosted Streamable HTTP, wrapped in a gated bug bounty operations pipeline where nothing leaves the machine without a recorded human approval. (https://derikcallahan.com/writing/three-gates-for-an-offensive-agent) - **Identity governance browser agent**: A Python orchestrator that lets a model drive a browser through provisioning and deprovisioning in applications with no API, with Teams approval cards before every write and a SHA-256 hashed screenshot audit trail. (https://derikcallahan.com/writing/an-agent-for-apps-without-apis) - **This site**: A static Astro site where every page has a Markdown twin, plus llms.txt, JSON Resume, content negotiation, and a read-only MCP endpoint — built so an AI agent can read it as easily as a person. (https://derikcallahan.com/writing/a-resume-for-two-audiences) ## Writing - [A resume for two audiences](https://derikcallahan.com/writing/a-resume-for-two-audiences) (2026-10-16): More and more, the first reader of a resume is an AI agent. So I built this site to be read by both people and agents — Markdown twins, llms.txt, JSON Resume, content negotiation, and a small read-only MCP server. - [The agent is an identity](https://derikcallahan.com/writing/the-agent-is-an-identity) (2026-10-07): Most AI risk conversations start with the model. I think they should start with the credentials. An agent can only do what its identity allows — so govern the identity. - [Agent traces are security telemetry](https://derikcallahan.com/writing/agent-traces-are-security-telemetry) (2026-09-30): If you can't replay what an agent saw, decided, and did, you can't investigate it. OpenTelemetry already gives us the format. The SOC needs to treat it like EDR data. - [An agent for apps without APIs](https://derikcallahan.com/writing/an-agent-for-apps-without-apis) (2026-09-12): Every identity program has a list of disconnected applications that someone provisions by hand. I built a proof of concept where a model drives the browser instead — with a human approving every write and a hashed screenshot behind every step. - [Three gates for an offensive agent](https://derikcallahan.com/writing/three-gates-for-an-offensive-agent) (2026-08-22): I built an MCP server for HackerOne and a bug bounty pipeline around it. The interesting part isn't the 174 tools. It's the three places where the agent has to stop and wait for me. ## Contact - Contact form: https://derikcallahan.com/contact - LinkedIn: https://www.linkedin.com/in/derik-callahan - GitHub: https://github.com/dcallahan - Location: Phoenix Metro, Arizona Full resume: https://derikcallahan.com/resume · Machine-readable: https://derikcallahan.com/resume.json · Agent guide: https://derikcallahan.com/agents --- # Derik Callahan — Resume Senior Manager, IT Security — Security Engineering & Operations AI risk & agentic security | Cyber operations & threat management | Zero Trust, identity & SSE modernization - Contact form: https://derikcallahan.com/contact - LinkedIn: https://www.linkedin.com/in/derik-callahan - GitHub: https://github.com/dcallahan - Location: Phoenix Metro, Arizona ## Summary Player-coach security leader with 15 years in IT and cybersecurity, 7 of them managing security teams. I lead security engineering and operations for a publicly traded company. Our 24/7 SOC runs through an MDR partnership at a mean time to detect under 5 minutes and a mean time to respond under 1 hour. We got there through detection engineering and SOAR automation, not added headcount. I rebuilt that SOC around agentic AI. Production agents triage phishing, endpoint, and identity alerts, and an analyst reviews every incident with AI doing the enrichment and investigation legwork. I sit on our AI Center of Excellence and architecture committee and lead safe AI adoption: use-case risk review, AI/MCP gateways, agent runtime guardrails, non-human identity controls, and OpenTelemetry tracing so the SOC can detect and investigate agent misuse. ## Experience ### Senior Manager, IT Security, Meritage Homes Corporation Scottsdale, AZ · 2021 – Present · Security Engineering & Operations Lead a team of security engineers and analysts across security operations, threat and exposure management, identity engineering, AI security, and compliance. **AI risk management & safe AI adoption** - Member of the AI Center of Excellence and architecture committee; set the governance model under which teams adopt AI and agents, and the risk review a use case clears before production. - Govern agentic AI at runtime through AI/MCP gateways, destructive-action controls, approval gates on high-impact operations, and execution sandboxing with least-privilege tool scoping. - Extended identity governance to non-human identities — machine, service, and agent identities scoped, guardrailed, and reviewed across credential and token lifecycle. - Instrumented AI agent trace monitoring with OpenTelemetry so prompt, tool-call, and action telemetry is retained and reviewable, feeding agent activity into detection and response. **AI-enabled security operations & response** - Run 24/7 SOC operations through an MDR partnership at MTTD under 5 minutes, triage under 20 minutes, and MTTR under 1 hour. - Put production AI agents in front of phishing, endpoint, and identity alert triage, with human review of every incident and AI handling enrichment, timeline reconstruction, and response recommendations. - Built the incident response program — IR plans, escalation paths, SOPs — and lead high-severity incidents through to durable remediation of the systemic cause. - Own ransomware protection, detection, and response: layered prevention, precursor detections, and isolation-to-recovery playbooks exercised through tabletops. - Own the threat lifecycle end to end — threat intelligence, hunting, red team coordination, and attack simulation wired into SIEM and SOAR. **Continuous exposure management** - Built a CTEM program unifying vulnerability management, SAST/DAST, CSPM, attack surface management, and penetration testing, prioritized by business risk rather than raw severity. **Zero Trust & platform modernization** - Set and enforce control standards across cloud, identity, endpoint, and application — EPP/EDR/XDR, ZTNA, SASE/CASB, DLP, WAF — with standards enforced as code through cloud policy. - Rolled out phishing-resistant, passwordless authentication to take passwords out of identity-based attack chains. - Consolidated overlapping tooling into a unified, automation-first stack. **Risk, metrics & team** - Oversee NIST CSF alignment and partner with Finance on SOX IT controls. - Grew interns into senior analysts and service desk staff into identity engineers. ### Cybersecurity Manager / Lead, USLBM Holdings Gilbert, AZ · 2019 – 2021 - Led security operations with a 24/7 SOC across enterprise and OT environments; wrote the IR plan and SOPs and led tabletop exercises. - Led security architecture for a large-scale Azure cloud migration, and consolidated 40+ acquisitions into one identity environment with Azure AD, MFA, and Conditional Access across 11,000 employees. ### Systems Engineer, R&K Building Supplies (USLBM) Gilbert, AZ · 2015 – 2019 - Managed Windows network and server infrastructure (Active Directory, Exchange, Cisco, VMware) and automated operations with Python, Bash, and PowerShell. ### Linux System Administrator, ServerHub Tempe, AZ · 2014 – 2015 - Led a team of 5 running Linux datacenter and IaaS infrastructure with high-availability design. ## Certifications - CISSP (ISC2) - CISM (ISACA) - AAISM — Advanced in AI Security Management (ISACA) - Cybersecurity Architect Expert (Microsoft) - Azure Administrator Associate (Microsoft) - Security Operations Analyst Associate (Microsoft) - Security+ (CompTIA) - CCNA (Cisco) ## Education - M.S., Management of Information Systems, University of Arizona — Graduate Certificate, Enterprise Cyber Security - B.S., Management of Information Systems, Northern Arizona University — Summa Cum Laude ## Skills - **AI & agentic security**: AI use-case risk review, AI / MCP gateways, Agent runtime guardrails, Approval gates, Execution sandboxing, OpenTelemetry agent tracing, Non-human identity, Prompt-injection & data-leakage controls, Azure AI Foundry - **Security operations**: Agentic AI SOC, Detection engineering, SIEM / SOAR, Microsoft Defender XDR, Incident command, Threat hunting, Threat intelligence, Ransomware response, Tabletop exercises - **Exposure management**: CTEM, Vulnerability management, SAST / DAST, CSPM, Attack surface management, Penetration testing - **Identity & Zero Trust**: Entra ID & ID Governance, Saviynt, Okta, Conditional Access, SAML / OIDC, FIDO2 / passkeys, ZTNA, SASE / SSE, CASB, DLP, Microsoft Purview, Azure Policy - **Engineering**: Python, PowerShell, Bash, TypeScript, Azure, Azure Logic Apps, CI/CD, Git, Linux, Windows Server - **Risk & leadership**: NIST CSF, KPI / KRI reporting, SOX IT controls, Vendor & MDR management, Team development --- # A resume for two audiences By Derik Callahan · 2026-10-16 · https://derikcallahan.com/writing/a-resume-for-two-audiences > More and more, the first reader of a resume is an AI agent. So I built this site to be read by both people and agents — Markdown twins, llms.txt, JSON Resume, content negotiation, and a small read-only MCP server. Recruiters, sourcing tools, and hiring managers increasingly put an AI between themselves and a resume. The model reads it first and summarizes it for the person. So I built this site for two readers: a person skimming in a browser, and an agent reading it on that person's behalf. ## The rule: one source, many renderings Everything about me lives in one typed data file and a folder of Markdown posts. Every surface is built from those two inputs at build time: - **HTML pages** for people. - **A Markdown twin of every page.** Add `.md` to any URL, for example [/resume.md](/resume.md) or [/writing/the-agent-is-an-identity.md](/writing/the-agent-is-an-identity.md). Each page also announces its twin with ``. - **[/llms.txt](/llms.txt)** and **[/llms-full.txt](/llms-full.txt)**, following the llms.txt convention: a short index, and everything in one file for a single fetch. - **[/resume.json](/resume.json)** in the JSON Resume schema, for tools that want structure instead of prose. - **schema.org JSON-LD** on every page: `Person`, `ProfilePage`, and `BlogPosting`. - **Content negotiation.** Request any page with `Accept: text/markdown` and you get the Markdown version at the same URL. The "Agent view" toggle in the header shows the exact Markdown an agent receives for the page you're on. A person can see the same thing a model sees. ## A read-only MCP server There's also a small [Model Context Protocol](https://modelcontextprotocol.io) endpoint at `/api/mcp`. It speaks stateless Streamable HTTP and offers a few tools: `get_profile`, `get_resume`, `list_posts`, `get_post`, and `search`. Point an MCP client at it and an agent can query my background directly instead of scraping HTML. I wrote it by hand without an SDK, which was a deliberate security choice: - **Read-only by construction.** Every tool returns data that's already public on this site. There's nothing to write, no secrets, and no state between requests. - **Small and auditable.** It's one file you can read in a few minutes. It parses JSON-RPC, checks the method, and returns content. Unknown methods get a standard error. - **Bounded.** Request bodies are size-capped, search queries are length-capped, and every response comes from a fixed in-memory corpus. There's no database or outbound call to abuse. It's the same thing I ask for from any MCP server at work: least privilege, a narrow surface, and nothing that would be a problem if an attacker controlled the input. ## Boring security, done properly A security leader's website should pass its own review: - The site is fully static except for the MCP function, so there is very little attack surface. - Strict headers: a Content-Security-Policy with no `unsafe-inline` scripts, HSTS, `frame-ancestors 'none'`, and a tight Permissions-Policy. - No third-party scripts, no trackers, and fonts hosted on this domain. - A [security.txt](/.well-known/security.txt) so researchers know how to reach me. - `robots.txt` explicitly welcomes AI crawlers. On this site, I want to be read. The [source is on GitHub](https://github.com/dcallahan/resumewebsite). Every change goes through a pull request with a Vercel preview build before it ships. --- # The agent is an identity By Derik Callahan · 2026-10-07 · https://derikcallahan.com/writing/the-agent-is-an-identity > Most AI risk conversations start with the model. I think they should start with the credentials. An agent can only do what its identity allows — so govern the identity. AI risk conversations tend to start with the model: is it aligned, can it be jailbroken, does it hallucinate. Those are real questions. But when I review an agent going to production, my first question is a different one: **what can it sign in as?** An agent can't delete what it can't reach. Whatever the model decides, the damage is capped by the permissions of the identity it uses. That makes identity the most dependable control we have, and the one security teams already know how to run. ## The non-human identity problem was already here Service accounts, service principals, API keys, and workload identities have outnumbered people in most environments for years. Many of them have no owner, never expire, and hold far more access than they need. Agents add to that population, with a difference: they decide what to do with their access at runtime, based on input that an attacker may control. A service account that runs a nightly job does the same thing every night. An agent with the same credentials does whatever its context window persuades it to do. ## What I apply to agent identities I extended our identity governance to cover machine, service, and agent identities with the same discipline we apply to people, plus a few rules specific to agents: - **One agent, one identity.** No shared service accounts across agents. If you can't tell which agent took an action, you can't investigate it or revoke just that one. - **A named human owner.** Every agent identity has a person accountable for it, who reviews its entitlements on the same cycle as privileged human access. - **Scope to the task, not the team.** An agent that reads invoices doesn't get write access to the finance system "in case it's needed later." Tool scoping and entitlement scoping are the same conversation. - **Short-lived credentials.** Tokens that expire in minutes, issued per task where possible. Credentials go in a vault, never in a prompt or config file. - **Act on behalf of, not as.** When an agent acts for a user, it should carry that user's delegated context, so it can't do more than the user could. An agent acting as a broadly privileged identity for anyone who asks is a confused deputy waiting to happen. - **Treat high-impact actions as step-up actions.** Just as a human needs re-authentication for sensitive operations, an agent's destructive operations route through an approval gate. ## Why this matters more than the model Models will keep changing, and every few months the jailbreak techniques change too. The identity layer is stable. It's auditable, it's already in your SIEM, and your access reviews and Conditional Access policies already apply to it. If I could only get one control in place before an organization deploys agents broadly, it would be this: every agent has its own identity, its own owner, and only the access its task needs. The guardrails, gateways, and tracing all matter, and I run all of them. But they work best on top of an identity layer that already limits the damage. --- # Agent traces are security telemetry By Derik Callahan · 2026-09-30 · https://derikcallahan.com/writing/agent-traces-are-security-telemetry > If you can't replay what an agent saw, decided, and did, you can't investigate it. OpenTelemetry already gives us the format. The SOC needs to treat it like EDR data. When an endpoint does something strange, my team can rebuild exactly what happened: the process tree, command lines, network connections, and file writes. EDR gave us that, and it changed incident response. When an AI agent does something strange, most organizations can rebuild almost nothing. Maybe there's a chat transcript. Maybe there's an API bill. The prompt that steered it, the documents it retrieved, the tools it called and the arguments it passed are gone, or they sit in a developer's debug log that nobody in security can query. That's the gap I spend the most time on. **An agent's trace is security telemetry, and it should be collected, retained, and watched like any other.** ## What to capture OpenTelemetry already has a model that fits agents: a trace made of nested spans. One user request becomes a root span. Each model call, retrieval, and tool call becomes a child span. The useful attributes for security are: - **Identity.** Which human started this, and which non-human identity the agent acted as. - **Inputs.** The system prompt version, the user prompt, and *where retrieved content came from*. Indirect prompt injection arrives in retrieved content. - **Tool calls.** The tool name, its arguments, and the result, including denials from a gateway or guardrail. - **Decisions.** Whether a human approved, rejected, or never saw an action that needed approval. None of this is exotic. The hard part is organizational: getting every team that builds agents to emit traces in the same shape and send them somewhere the SOC can see. ## What to detect Once traces land in the SIEM, the detections start to resemble ones we already know: - **Tool use the task doesn't explain.** A summarization agent that calls a send-email tool. That's the agent version of Word spawning PowerShell. - **Injection markers in retrieved content**, especially when a tool call happens right after them. - **Data leaving through an unexpected route.** Large tool arguments going to external destinations, or sensitive labels showing up in outbound content. - **Guardrail denials that cluster.** One blocked call is noise. Twenty from the same session is someone probing. - **Drift.** An agent identity suddenly using tools or data it has never touched before. ## Where gateways fit An AI or MCP gateway gives you a choke point. It can enforce which tools an agent may call, inspect arguments, and require approval for destructive actions. It's also the natural place to emit consistent telemetry. But a gateway without trace retention is a firewall without logs: it will block things, and you'll never know what it saw. ## The test Here's the question I ask about any agent going to production: **if this agent does something harmful at 2 a.m., can the on-call analyst rebuild what happened by 2:30?** If the answer is "we'd have to ask the developer," it isn't ready yet. --- # An agent for apps without APIs By Derik Callahan · 2026-09-12 · https://derikcallahan.com/writing/an-agent-for-apps-without-apis > Every identity program has a list of disconnected applications that someone provisions by hand. I built a proof of concept where a model drives the browser instead — with a human approving every write and a hashed screenshot behind every step. Every identity governance program has the same embarrassing appendix: the disconnected applications. These are systems with no SCIM, no API, and no connector, where provisioning and deprovisioning happen because someone works through a ticket by hand. They're usually the accounts that outlive the employee. Browser agents looked like a real answer, so I built a proof of concept to see whether one could hold up to audit. ## How it works A Python orchestrator gives a model (Claude, served through Azure AI Foundry) control of a browser through Playwright. The model sees a screenshot, works out what's on the page, and decides what to click, type, or open next. The task is plain identity work: create the account, assign the role, disable the user. Three things make it more than a demo: - **A YAML agent factory.** Each application's workflow is a template, not code. "Deprovision a user in app X" is a short YAML file with inputs and a goal. Adding a new disconnected app means writing a template, not shipping a release. - **Human approval before any write.** Read steps run freely. Before a write that changes access, the orchestrator posts an adaptive card to Microsoft Teams with what it plans to do and the current screenshot. An approver confirms or denies it, and the task waits until they do. - **An evidence pipeline.** Every step's screenshot goes to blob storage with its SHA-256 hash, alongside a JSON audit log of every model decision. When an auditor asks "how do you know this user was removed," the answer is a sequence of hashed images showing that it happened. It runs as a small HTTP service: start a task, check its status, receive the approve or deny callback. ## What I learned **The model is the easy part.** Modern models are good at reading a screenshot of an admin console. The engineering effort goes into everything around the model: timeouts, retries, knowing when a page has actually finished loading, and refusing to continue when the screen doesn't match what was expected. **Evidence changes the conversation.** Security and audit teams don't trust "the bot did it." They do trust a tamper-evident record of what the bot saw and did at each step. The screenshots matter more to the business case than the automation does. **The agent is an identity too.** The browser agent signs into the target app with a real account that has real privileges. That account needs the same treatment as any privileged identity: scoped to the minimum, credentials in a vault, sessions recorded, access reviewed. I wrote more about that in [the agent is an identity](/writing/the-agent-is-an-identity). **Approval fatigue is the real risk.** If every step needs a click, approvers stop reading. Gating only the writes that change access, and showing a screenshot instead of a JSON blob, is what keeps the human actually reviewing. This is still a proof of concept, not a product. But it changed my view on disconnected apps. Their real problem was never the missing API. It was the missing evidence. --- # Three gates for an offensive agent By Derik Callahan · 2026-08-22 · https://derikcallahan.com/writing/three-gates-for-an-offensive-agent > I built an MCP server for HackerOne and a bug bounty pipeline around it. The interesting part isn't the 174 tools. It's the three places where the agent has to stop and wait for me. I wanted to find out how far an AI agent can go in bug bounty work, so I built the tooling to try. The first piece was an MCP server for the full HackerOne REST API: both the Customer and Hacker sides, 174 tools, running over stdio locally or hosted over Streamable HTTP. With it, an agent can read program policies, check scope, pull its own report history, and draft submissions. That was the easy part. A model that can call 174 tools will happily call all of them. What took real design work was deciding where it must not act on its own. ## The pipeline The work runs as a pipeline, and the human decisions are explicit steps in it, not a matter of the agent being polite: 1. **Rank programs.** A scoring script reads public program data and ranks targets. Read-only. Nothing touches a target. 2. **Gate 1: pursue.** The harness writes a proposal. I approve or reject it with a command that records the decision. No approval, no engagement. 3. **Onboard.** The engagement gets its own folder, a snapshot of the program policy, and a written scope file. 4. **Gate 2: authorized to test.** This is the line before any packet leaves the machine. The agent has to show that the target, technique, and rate limits map to the written scope. 5. **Recon, mapping, micro-scoped testing.** One bug class per run, passive before active. 6. **Reproduce or discard.** If it doesn't reproduce on the live in-scope target, there's no report. 7. **Gate 3: submit.** Nothing goes to a program under my name until I've read it. ## Why gates, not prompts You can tell a model "only test in-scope assets," and most of the time it will listen. But "most of the time" is the wrong standard when the failure is unauthorized access to someone else's system. A rule written in a prompt is a suggestion. A gate is a control: the next step physically can't run until a decision has been recorded. Each gate puts a person at the point where the stakes change: - **Gate 1** is a business decision: is this worth my time? - **Gate 2** is a legal one: am I allowed to do this? - **Gate 3** is about reputation: am I willing to sign this? Between the gates, the agent is free to go fast. That's the trade I'd make in any company too. Let automation run hard inside a box, and put humans on the edges of the box. ## What carries over to the enterprise This is the same pattern I use for agents at work, just applied to offense. The terms there are destructive-action controls and approval gates on high-impact operations. But the shape is the same: - **Sort actions by blast radius, not by tool name.** Reading a policy and submitting a report can go through the same API client. They aren't the same risk. - **Record the approval as data.** A Slack thumbs-up doesn't count. The approval should be a record the next step checks, with who approved it, when, and what exactly they approved. - **Make the safe path the fast path.** If the gate is slow, people will build their way around it. My approvals are one command. The tooling makes the agent capable. The gates make it something I'm willing to run.