The First Question Security Teams Ask
When evaluating any cloud security platform, the first question from security-conscious teams isn’t about features. It’s about footprint:
“What do you deploy in our environment?”
This is the right question. Every component running in your cloud account is:
- An attack surface (can it be compromised?).
- A maintenance obligation (does it need patching?).
- A resource consumer (does it cost money? Does it impact performance?).
- A dependency (if it goes down, does something break?).
For Cloud Console JIT — the capability that manages permission set assignments in AWS IAM Identity Center — Cloudanix’s answer is: nothing deployed. One IAM role assumed. That’s it.
The Architecture: Role Assumption, Not Agent Deployment
What Exists in Your Account
When you onboard a cloud account for JIT access, a CloudFormation stack creates one resource:
An IAM cross-account role with:
- A trust policy allowing Cloudanix’s AWS account to assume it.
- Permissions scoped to what the platform needs (Identity Center operations for JIT, or broader read for CSPM if enabled).
- Optional explicit deny statements for services you don’t want the role to access.
That’s the complete footprint. No Lambda function. No ECS task. No EC2 instance. No VPC. No security group. No ENI. No CloudWatch agent. No daemon running anywhere.
How JIT Operations Execute
When an engineer’s access request is approved:
- Cloudanix’s control plane (running in Cloudanix’s infrastructure, not yours) initiates the IAM operation.
- It assumes the cross-account role in your AWS account using AWS STS.
- It calls the IAM Identity Center API to create or remove a permission set assignment for the specific user.
- The API call completes — the permission set is assigned (or unassigned).
- The assumed role session ends.
The entire operation is an API call sequence: AssumeRole → CreateAccountAssignment (or DeleteAccountAssignment) → done. No persistent process. No running agent. No infrastructure to maintain.
What This Means Practically
| Concern | Answer |
|---|---|
| “Does it run in my VPC?” | No. No VPC resources created. |
| “Does it consume compute?” | No. No Lambda, ECS, or EC2 instances. |
| “Does it need patching?” | No. No running software in your account. |
| “Can I audit its API calls?” | Yes. Every API call appears in your CloudTrail. |
| “Can it access my data?” | Only if you grant those permissions. JIT-only deployments don’t. |
| “What if Cloudanix goes down?” | No running agent to crash. Existing access remains until expiry. No new grants until service restores. |
| “How do I remove it?” | Delete the CloudFormation stack. One action. Everything gone. |
Why Agentless Matters for Security Teams
Attack Surface Minimization
Every component in your environment is a potential compromise vector. A Lambda function can be invoked unexpectedly. An ECS task can be exploited if its container image has vulnerabilities. An EC2 instance is a server that needs OS patches. A VPC endpoint is a network path that could be misconfigured.
An IAM role with a trust policy is the minimum possible footprint:
- It can’t be “compromised” in isolation — it requires valid credentials from the trusted account.
- It has no running process to exploit.
- It has no network presence to attack.
- It has no software to patch.
- Its only capability is defined by the IAM policy attached to it.
CloudTrail Visibility
Every action Cloudanix takes in your account appears in CloudTrail. When the platform assumes the role and makes an Identity Center API call, that event is logged with:
- The role ARN that was assumed.
- The source account (Cloudanix’s account) that assumed it.
- The specific API call made (CreateAccountAssignment, DeleteAccountAssignment).
- The target resources (user ID, permission set, account).
- Timestamps.
Your security team can monitor these events, set up alerts, and verify that the role is only performing expected operations. Full transparency, no black box.
Permission Boundary Control
The IAM role’s policy is the complete definition of what Cloudanix can do in your account. If the policy allows sso:CreateAccountAssignment and sso:DeleteAccountAssignment, that’s all the platform can do. Period.
You control the policy. You can:
- Restrict to specific permission sets (Cloudanix can only assign SecurityAudit and Developers_Editor, not AdministratorAccess).
- Add explicit deny statements (even if the policy is broader, deny specific actions you don’t want).
- Limit to specific Identity Center instances (if you have multiple).
- Use Service Control Policies at the OU level for additional boundaries.
The security team defines the boundary. Cloudanix operates within it.
The Exception: Database JIT
There’s one JIT surface where infrastructure is deployed in the customer’s account: Database JIT.
Database JIT requires a component (ECS service) running in the customer’s VPC to reach RDS instances in private subnets and broker connections. This component:
- Runs in the customer’s VPC, in their private subnet.
- Is owned by the customer (their ECS service, their IAM policy, their logs).
- Communicates outbound to Cloudanix’s control plane via HTTPS.
- Does not expose any inbound network surface.
This architectural difference is driven by the access pattern: database connections require network-layer brokering that can’t be done purely through IAM API calls. Cloud Console JIT (which operates through IAM Identity Center APIs) doesn’t need this — it’s purely control-plane operations.
The distinction:
- Cloud JIT, Kubernetes JIT, SaaS JIT: Agentless. Cross-account role only.
- Database JIT: ECS component in customer’s VPC (required for private subnet connectivity).
- Agentic JIT: SDK calls from the customer’s pipelines/workloads. Cloudanix provides the library; execution is in the customer’s environment.
Onboarding: 30 Minutes to Connected
The agentless model means onboarding is fast:
- Run CloudFormation stack (provided by Cloudanix) — creates the IAM role. Takes 2 minutes.
- Connect the account in the Cloudanix Console — validates the role can be assumed. Takes 30 seconds.
- Sync Identity Center data — reads users, groups, permission sets, and account assignments. Takes 5–10 minutes.
- Configure JIT policies — map groups to accounts and permission sets, set approval rules. Takes 15–20 minutes.
- Test — make a request, get approved, verify in SSO portal. Takes 2 minutes.
Total: under 30 minutes from “we haven’t connected any accounts” to “engineers can request JIT access.”
No infrastructure provisioning. No network configuration. No container deployment. No agent installation. No DNS changes. No security group modifications.
Removal: Equally Fast
If you decide to stop using Cloudanix:
- Delete the CloudFormation stack in your account.
- The IAM role is removed.
- Cloudanix can no longer assume any role in your account.
- No residual infrastructure. No orphaned resources. No cleanup.
Complete removal in one action. This is only possible because there’s nothing else deployed — no ECS services to decommission, no Lambda functions to delete, no log groups to clean up (for Cloud JIT).
The Trust Model
Agentless doesn’t mean “no trust.” You’re trusting Cloudanix with the ability to make IAM Identity Center API calls in your account. That trust is:
- Bounded by the IAM policy you attach to the role.
- Auditable through CloudTrail.
- Revocable by deleting the role (instant, unilateral, no coordination needed).
- Scoped to the APIs you’ve permitted (and nothing else, ever).
The trust relationship is explicit, visible, and under your control. Compare this to agent-based models where a running process in your VPC could theoretically do anything its runtime environment permits — and you’d need to reverse-engineer its behavior to verify.
Ready for Zero-Footprint JIT?
If your security team requires minimal deployment footprint — no agents, no Lambda functions, no ECS tasks running in your account — Cloudanix Cloud JIT operates entirely through a single IAM cross-account role. One role, visible in CloudTrail, bounded by your IAM policy, removable in one click.
Learn more about JIT access architecture or book a demo to see agentless onboarding in real time.
