Deploy the self-contained Araghatta sensor to EC2 and Linux today, and to Windows Server in beta — and to Azure VMs or Google Compute Engine as those connectors come online. It identifies the AI agent and its local capabilities; a read-only AWS connector adds workload identity, metadata-service, policy, storage and service posture today, with Azure and Google Cloud connectors being brought online. The platform correlates the evidence to show what the agent could reach and which control breaks the path.
Traditional CSPM reports cloud settings. Endpoint tools report processes. Araghatta joins both perspectives so teams can distinguish a theoretical control gap from an AI-enabled path with real workload context.
01 · RUNTIMEObserve the AI agentIdentify the framework, process tree, service/container, execution owner, unattended operation and bounded tool capabilities.02 · HOSTConfirm preconditionsAssess metadata-service configuration, local reachability, network egress, isolation and host policy.03 · IDENTITYCalculate effective accessResolve the workload identity through policies, conditions, boundaries, organisation controls and resource policies.04 · RESOURCEMap reachable servicesIdentify storage and cloud services the identity is authorised to access, without opening customer data.05 · PRIORITYBreak the pathRank by confidence and blast radius, route remediation and verify that the exposure edge is closed.AWS findings merge local sensor telemetry with customer-authorised, read-only organisation and account APIs. Evidence remains attributable to the instance, role, policy and affected resource.
| Layer | Evidence evaluated | Risk decision | Enterprise remediation |
|---|---|---|---|
| AI agent runtime | Agent/framework, executable and package, process ancestry, service/container, execution identity, unattended state, network access and code/shell/file/tool capability classes | Could the process make autonomous calls, influence local execution or reach workload services? | Constrain tools and egress, require approval for sensitive actions, isolate or stop the agent through the authorised response path |
| EC2 workload | Instance ID, account, region, image, tags, VPC/subnet/security-group context, instance profile and sensor identity | Is the agent running on a sensitive or internet-reachable workload, and what cloud identity is bound to it? | Move the workload to an appropriate trust zone, restrict network paths and correct ownership or classification |
| Instance metadata | Metadata endpoint state, IMDSv1 availability, IMDSv2 token requirement, hop limit and bounded local reachability evidence | Do host and agent capabilities create the preconditions for unintended workload-identity access? | Require IMDSv2, set an appropriate hop limit, disable metadata where unnecessary and remove the vulnerable local precondition |
| IAM and organisation policy | Instance role, identity policies, permission boundaries, session constraints, SCPs, resource policies, trust relationships, conditions, wildcards and privilege-escalation edges | What is the effective action/resource scope, including cross-account and role-delegation paths? | Apply least privilege, add resource and condition constraints, remove escalation edges and separate build/runtime duties |
| Amazon S3 | Bucket policy and ACL posture, Block Public Access, encryption, logging, versioning, Object Lock, data classification tags and action classes allowed to the workload identity | Could the workload identity list, read, alter or delete sensitive storage, even when the bucket is not public? | Constrain bucket and identity policies, enable protective controls and monitoring, rotate or revoke exposed sessions where required |
| Corroborating services | CloudTrail, AWS Config, Security Hub, GuardDuty, VPC flow context and Security Lake/OCSF findings | Is the path a configuration exposure, an observed attempt or an active incident? | Enrich the finding, escalate to the SOC and preserve the original evidence and timestamps |
The graph is conditional: every edge records its evidence, freshness and confidence. If any precondition is absent, the path is downgraded or closed.
OBSERVEDAutonomous agentRuns unattended with broad code or tool capability on an EC2 workload.PRECONDITIONMetadata exposureIMDSv1 remains available or the workload boundary does not enforce the intended metadata control.IDENTITYOver-scoped roleThe attached instance role has effective permissions beyond the workload’s business purpose.RESOURCESensitive S3 accessIdentity and bucket policy permit sensitive storage action classes.OUTCOMEMaterial cloud riskA manipulated or compromised agent could act beyond the server boundary; remediate the shortest verified edge first.No metadata credential is requested or retained, no temporary credential is replayed, no S3 object is opened and no exploit payload is executed. Optional validation uses customer-approved, non-destructive checks with audit evidence.
AWS is generally available today. The Azure and Google Cloud connectors are read-only and being brought online — the models below describe what each connector collects on connect. Provider concepts are normalised for cross-cloud reporting while the original resource IDs, policy semantics and remediation guidance remain intact.
Every finding preserves the source and time of each fact so analysts can separate observed runtime, retrieved configuration and derived risk.
| Finding field | What the analyst receives |
|---|---|
| Asset and owner | Cloud provider, organisation/account/subscription/project, workload resource ID, hostname or tokenised host ID, region, environment, owner and business service |
| AI runtime | Agent/process identity, framework/package version, service/container, execution principal, unattended state and bounded tool capability classes |
| Attack path | Ordered nodes and edges, prerequisites, effective identity, reachable action classes, affected resources and blast-radius summary |
| Evidence quality | Observed/retrieved/derived label, source sensor or API, collection time, freshness, confidence, policy version and correlation rationale |
| Prioritisation | Likelihood, impact, exploit-precondition strength, sensitive-data context, existing compensating controls and risk/threat scores |
| Remediation | Ordered controls that break the path, owner, due date, ticket/SIEM linkage, exception workflow and post-change verification |
Discovery and analysis are non-destructive. Response and remediation are separate, explicitly authorised controls with narrow permissions and rollback.
Cloud connectors use published least-privilege roles/scopes created, restricted, rotated and removable by the customer.
Metadata configuration and identity references are collected; temporary credentials, access-key values and private keys are excluded.
Storage configuration, policy and permitted action classes are evaluated without downloading or opening customer objects.
Pause and server-side device revocation are available today, operator-authorised and audited. Agent isolation and inline policy enforcement are on the roadmap; when they ship they will require scoped authorisation, dry-run where supported and emergency disable.
We will demonstrate how the sensor identifies the AI runtime, how the connector resolves effective cloud access, how the attack path is evidenced and which remediation closes it—without touching credentials or customer data.