Define what your AI workflow can trust, what it can reach, and which actions must remain under engineering control.
When a useful tool becomes a system dependency.
An agent that retrieves documents, invokes tools, or changes business records crosses several security boundaries. Identity, authorization, untrusted content, and operational control need to be designed together.
I bring application-security engineering and direct experience building retrieval/MCP tooling to reviews of AI-integrated workflows. The goal is a clear set of boundaries and controls that your team can implement and verify.
Focused engagements
A focused starting point
Security architecture review
Where are the most consequential design risks?
What you bring
Architecture diagrams, data flows, security requirements, and access to the engineers who own the system.
Scope
One agreed system or integration boundary. Implementation and penetration testing are scoped separately.
What you receive
Architecture findings, prioritized remediation, and an engineering debrief.
Timing
Agreed after reviewing system scope, access, and evidence availability.
I built and operate a local-first retrieval platform that serves source and documentation context to MCP clients. The work includes document conversion, content-aware indexing, hybrid search, and context persistence across engineering sessions.
The accompanying engineering practice keeps requirements traceable, design decisions explicit, execution permissions bounded, and verification under human control. This is internal engineering-tooling experience; the illustrative threat model below demonstrates how I would structure a review of another workflow.
Data and retrieval: ingestion, provenance, access boundaries, retention, and prompt-injection exposure.
Tools and identity: authorization at the tool boundary, least privilege, and separation between proposed and executed actions.
Operations: logging, human review, recovery paths, and verification of outputs before they become authoritative.
Evidence: documented assumptions, misuse scenarios, and a prioritized control roadmap.
Illustrative deliverable · not a client architecture
A boundary worth making explicit.
01 / Untrusted contextDocuments & retrieved text
Content can inform the answer. Instructions embedded in it must not confer authority.
02 / Decision boundaryAgent proposes an action
Check the user's authority, tool scope, and required human approval before execution.
03 / Trusted operationTool enforces permissions
Validate arguments, record the action, and verify its result against the intended change.
Example misuse: a retrieved document tells an agent to export customer records. The control belongs at the authorization and tool boundary; a trusted-looking document is not permission.