Zero Trust is a multi-decade-old concept, but most organizations still struggle to move from reading about it to actually implementing it. The challenge is not conceptual — it is operational. How do you get leadership buy-in, structure the rollout, and maintain usability while adding security controls at every layer?
We spoke with Uttej Badwane, Senior Security Engineer at Carta, on the Scale to Zero podcast. With nearly a decade of hands-on experience leading cloud and corporate security initiatives at high-growth Silicon Valley startups, Uttej breaks down Zero Trust into practical, implementable steps and explains how AI agents are creating new challenges for the model.
You can read the complete transcript of the episode here >
What are the three pillars of Zero Trust?
Uttej simplifies Zero Trust into three core components that must communicate with each other continuously:
-
Identity: Who is making the request? This covers MFA, group-based access, lifecycle management through identity providers like Okta integrated with HRIS systems, and attribute-based group assignments.
-
Devices: What device is the request coming from? This involves MDM tools, device certificates, encryption checks, firewall status, and ensuring only corporate-managed devices can access sensitive resources.
-
Policy Engine: How is access being granted? This is where micro-segmentation, conditional access rules, port restrictions, API method controls, and infrastructure-level policies live. Tools like Zscaler install daemon clients in cloud-native clusters to enforce these policies.
If any one step is broken, access is broken. That interconnection is what makes Zero Trust more robust than VPN or MFA alone — those are individual checks within the framework, not substitutes for it.
How do you get started with Zero Trust implementation?
The first step is not technical — it is organizational:
- Get leadership buy-in early. Zero Trust requires budget, resources, and cultural change across the entire organization. Without CISO or CTO sponsorship, the initiative will stall.
- Build a coalition of teams. You need infrastructure/SRE, developer experience, IT, and security aligned. Each owns a piece of the implementation.
- Inventory your assets. Know what cloud resources exist, who accesses them, and how they access them (home network, personal device, corporate device).
- Show risk to leadership. Map attack vectors — employees connecting from public WiFi directly to databases, everyone having admin access — and demonstrate the potential downside.
At Carta, Uttej’s approach was staged: get identity strategy right first (group rules, lifecycle management, HRIS integration), then layer device controls (certificates, MDM checks), then build the policy engine with infrastructure segmentation.
How should you handle IAM in a Zero Trust model?
For human identities in AWS:
- Eliminate IAM users with long-lived access keys. Use IAM roles with short-lived credentials (STS tokens via AWS SSO/Identity Center) instead. Access keys that never expire are keys to the castle if a laptop is stolen.
- Integrate identity providers with AWS SSO. Okta or similar providers generate temporary STS tokens when users click their AWS tile — no permanent credentials stored anywhere.
- Use permission sets with least privilege. Production accounts require a two-step approval process: ticket approval plus a reviewed pull request. No one gets admin access by default.
For non-human (machine) identities:
- Use OIDC federation where possible (e.g., GitHub Actions connecting to AWS without access keys).
- Run AWS Access Analyzer to identify unused permissions and stale machine identities.
- Apply naming conventions so you can actually identify what each machine identity does.
- Isolate workloads in separate AWS accounts using multi-account strategy to limit blast radius.
How do you govern Zero Trust without creating friction?
The balance between security and usability is the hardest part. Uttej’s principles:
- Think of employees as your customers. If they need too many clicks or manual steps to do their daily work, you have gone too far.
- Automate certificate management. Push config files through MDM rather than requiring manual installation. Extend certificate expiry to 7 days instead of 24 hours to reduce friction.
- Use automated access auditing. Write detection rules in your SIEM (Splunk, Panther) that identify unused access over 60 days, then automatically ping users via Slack asking if they still need it. If no response, revoke.
- Run quarterly surveys. Ask employees directly: is access easy or cumbersome? Use that data to fine-tune policies.
- Apply strict controls only where risk justifies it. Production accounts with customer data get two-step approval. Sandbox environments get lighter controls.
When is Zero Trust the right fit?
There is no universal formula. Uttej’s guidance:
- Under 20 employees: Probably not worth the investment yet. Focus on building and selling the product.
- Beyond 100 employees: You must start thinking about it. Risk grows exponentially as more people access more resources.
- Sensitive data regardless of size: If you handle defense contracts, healthcare data, or financial PII, even a 10-person company needs fine-grained controls.
The key question for any security leader: “Am I comfortable with everyone having access to this data?” If the answer is no, it is time to implement Zero Trust.
How does AI change the Zero Trust equation?
AI creates both opportunities and new challenges for Zero Trust:
Where AI helps:
- Identity providers are becoming AI-enabled, surfacing access patterns and flagging unused permissions automatically.
- Automated auditing can detect anomalies and trigger access reviews without human intervention.
- Policy recommendations can be generated based on actual usage patterns.
Where AI creates new risks:
- Shadow AI tools (meeting notes apps, Grammarly, enterprise search) can bypass all Zero Trust controls if given admin-level access to read across systems. Vendor due diligence with strong SLA agreements about data training and retention is essential.
- AI agents with autonomous decision-making need the same blast radius thinking as any other workload. Isolate them in dedicated AWS accounts with granular VPC-to-VPC communication and strict IAM policies.
- MCP servers and API keys introduce new non-human identities that need the same governance as any other machine credential — who controls creation, what access they grant, and how they are rotated.
The fundamentals do not change even as technology evolves. Identity, device checks, and policy engines still form the foundation. What changes is the attack surface and the speed at which new identities and access patterns emerge.
