Rakesh Bhavandlapelli | Systems in Motion

I built this to show how I think about security.

I’m Rakesh Bhavandlapelli, a Security Engineer at Amazon. My work sits across application security, AI and GenAI governance, third-party security assessments, cloud risk, vulnerability management, and incident response.

The short version: Virginia Tech taught me how real systems fail. AWS taught me what happens when security decisions have to scale. Amazon is where I’m applying that thinking to AI adoption, vendor trust, and builder-safe security.

AI Trust Application Security Third-Party Risk Cloud-Scale VM

Three chapters built the lens: live-system security research at Virginia Tech, scale and prioritization at AWS, and AI/vendor/application trust work at Amazon.

01 / Virginia Tech

Virginia Tech is where I learned security on live systems.

I spent three years inside Virginia Tech’s IT Security Office. That mattered because the work was not theoretical. The systems were live, the users were real, and the defenders had to make decisions with incomplete signals.

Worked across red team, purple team, incident response, vulnerability management, and secure code review.Studied how attacks move through real authentication flows, browser behavior, API boundaries, and vulnerable code.Learned to treat attacks as paths through assumptions, not isolated checklist items.

02 / AWS

AWS is where vulnerability management became a scale problem.

At AWS, the issue was not a lack of findings. The issue was making the right prioritization call across cloud-scale infrastructure, where one bad assumption can propagate across teams and remediation timelines.

Worked on host operating system vulnerability management across AWS-scale infrastructure.Built data alignment, automation, forecasting, and dashboard workflows to make risk easier to act on.Learned that scalable security looks more like product engineering than manual ticket routing.

03 / Amazon

Amazon is where I work on AI, applications, vendors, and cloud risk together.

Today I’m a Security Engineer at Amazon. The role is broad by design, but the center is clear: help teams move fast without losing control of trust, data, and risk.

Review applications, architecture, and security design before production decisions harden.Evaluate third-party vendors before sensitive data crosses into systems we do not operate.Help define practical AI and GenAI governance patterns so builders can adopt AI safely.

04 / Orisan

Orisan is where I’m turning that thinking into a product direction.

Orisan comes from the same question I’m working on professionally: how can teams adopt AI without losing control of sensitive data? The goal is a trust layer, not another dashboard.

Make data boundaries visible before AI adoption becomes irreversible.Map vendor exposure, retention paths, and governance obligations.Turn AI trust from policy language into an operational workflow teams can actually use.

Orisan is the problem I work on every day, turned into a product.

I'm building Orisan, an AI trust platform that sits between enterprises and every AI tool their employees use. The problem is one I encounter daily: organizations are adopting AI faster than their security teams can govern it, and the tools to close that gap do not exist yet.

Orisan makes data boundaries visible before AI adoption becomes irreversible. It sanitizes what goes into AI tools, governs which tools are approved, and keeps security teams in control without blocking the productivity that made AI worth deploying.

I'm looking for security leaders who want to be involved early as design partners, advisors, or early users. If that's you, reach out.

Why blocking AI tools doesn't work, and what to do instead.

Every security team I talk to has the same instinct: when employees use an AI tool we haven't approved, block it. It makes sense. The problem is it doesn't work. Blocking creates shadow usage: employees find workarounds, use personal accounts, or switch to mobile. You lose visibility entirely. The data is still leaving. You just can't see it anymore. The answer is not permissive either. It's governance that moves at the speed of adoption. Approve a set of tools with clear data handling requirements. Route usage through a layer that sanitizes sensitive data before it reaches the model. Give security teams the audit trail they need without giving developers a reason to route around the controls. That is what makes AI adoption sustainable, not a policy that employees work around by lunchtime.

I built this to show how I think about security.

Virginia Tech is where I learned security on live systems.

AWS is where vulnerability management became a scale problem.

Amazon is where I work on AI, applications, vendors, and cloud risk together.

Orisan is where I’m turning that thinking into a product direction.

Orisan is the problem I work on every day, turned into a product.

Why blocking AI tools doesn't work, and what to do instead.

Proof that the story is not just positioning.

AI adoption without data control loss

Fleet-scale vulnerability prioritization

Third-party trust before data movement

Security research in live systems