AI security, platform delivery, architecture
Computer Science graduate from Arizona State University with experience across cloud delivery, security engineering, model-backed product workflows, Kubernetes operations, and the evidence trail that makes a system trustworthy after it reaches production.
$kien trace model-flow --policy --tools --evidence
A model workflow where prompts, retrieval, tool permissions, eval results, logs, and rollback notes are visible from the start.
User, tenant, role, and service context stay attached to the model request.
Retrieval, tool calls, and outputs pass through checks that can be reviewed.
Failures leave traces, release notes, and enough context for replay.
Each lane points to a public-safe artifact that shows the shape of the work, not just a keyword list.
Model features with governed tools, visible traces, eval checkpoints, and rollback paths.
Access-control proof, hardening plans, abuse-case review, and remediation engineers can ship.
Kubernetes services with clean promotion, rollout discipline, observability, and recovery notes.
Service boundaries, identity flows, data movement, risks, tradeoffs, and stakeholder handoff.
working profile
The common thread is operational clarity: know the boundary, ship with rollback, observe the failure path, and write the artifact clearly enough that another engineer can act on it.
I am strongest on systems where reliability, security, and product delivery are tangled together: AI tools with real permissions, platform changes with real blast radius, and architecture work that must survive implementation.
I treat model-backed features like production software: inputs are bounded, tool calls are governed, failures are observable, and releases have rollback paths.
I move security work past scanner output by mapping the boundary, proving impact carefully, and translating findings into controls teams can actually ship.
I focus on the operating details that keep services reliable: deployment hygiene, Kubernetes ownership, rollback discipline, logs, metrics, and runbooks.
I turn ambiguous requirements into service boundaries, identity flows, data movement notes, rollout plans, and tradeoffs that engineers can build from.
selected work
These are intentionally sanitized, but they are written like real working documents: what problem exists, what boundary matters, what evidence proves it, and what a team should do next.
A production-oriented design for routing model traffic through identity-aware policy, retrieval checks, tool permissions, eval gates, logs, and replayable incidents.
Frames AI work as an operating system, not a prompt demo: every request has context, every tool action has a permission boundary, and every failure leaves evidence.
Boundary: Architecture is representative and sanitized. It does not publish private prompts, datasets, customer data, internal controls, or unsafe abuse detail.
Open artifactA delivery model for services that need predictable builds, Kubernetes readiness, progressive rollout, observability, ownership, and rollback instructions.
Makes release safety concrete: a service is not production-ready just because it deploys. It must be observable, recoverable, owned, and easy to reason about during failure.
Boundary: No private cluster names, customer services, credentials, environment details, or internal network diagrams are included.
Open artifactA report-building workflow that turns scoped testing into defensible evidence: request pairs, object-boundary checks, denied controls, impact notes, and remediation language.
Shows practical security judgment: boundary proof, impact clarity, false-positive reduction, and remediation guidance matter more than raw scanner output.
Boundary: Authorized testing only. No private target details, unsafe reproduction detail, secrets, customer data, or risky step-by-step instructions.
Open artifactAn operating model for model-backed products: trace fields, evaluation checkpoints, prompt and retrieval release notes, cost visibility, latency budgets, and incident review.
Bridges ML delivery, platform engineering, and security so model behavior can be measured, debugged, governed, and improved after it leaves a notebook.
Boundary: Examples are synthetic and sanitized. No private prompts, datasets, user conversations, internal traces, or customer content are published.
Open artifactresume signal
Recent work is framed around ownership, control design, observability, release safety, and handoff.
Security engineering work across application flows, cloud risk, control design, and evidence handling, with emphasis on turning technical findings into remediation paths engineers could own.
Cloud and delivery work around deployment pipelines, Kubernetes operations, build hygiene, observability, and the production habits that make services safer to change.
Authorized vulnerability research outside day-to-day work, focused on access-control boundaries, mobile/API behavior, auth state transitions, and proof packages that can survive triage.
resume summary