Tara · Discovery · Road to V1
Where we are on the way to V1 — what shipped, what's in flight, and what's next. One source for leadership, product, and engineering.
V1 progress at a glance
The destination
V1 is the Discovery module, feature-complete. Tara detects AI agents and Non-Human Identities across AWS, GCP, Azure, GitHub, the identity backbone (Google Workspace / M365), and the endpoint — pulls control-plane state and audit logs (never proxies traffic), and produces a typed identity-and-access graph plus a findings feed.
The engine — connectors, IAM blast-radius expansion, privilege-escalation detection, risk scoring, cross-integration correlation, and the access graph — is built and running today. V1 closes the remaining gaps: the last UI surfaces, deeper Azure/GitHub coverage, and the governance/platform rails (RBAC, self-audit, alerting) that make it deployable in a customer's environment.
Discovery is phase one of the broader Discover → Govern → Intervene harness. Govern and Intervene begin after V1.
Product / TPM view
Each lane is a sprint, each card a deliverable. Reconstructed on a two-week cadence from the delivery history (mid-April → end-May 2026) and the roadmap. S0–S3 shipped · S4 is current · S5–S7 and the parked lane are ahead. Scroll the board horizontally →
→ Apr 11 · Stand up a secure, contract-locked backend the whole product can build on.
Apr 14 – 25 · Answer "what AI is running in AWS, and what can it reach?" end-to-end.
Apr 28 – May 9 · Extend beyond one cloud — add GCP and the shadow-AI identity surface.
May 12 – 23 · Catch local/IDE AI that never touches corporate identity, and rebuild the IA around it.
May 26 – Jun 6 · Turn per-cloud findings into one cross-cloud story — who reaches what, across providers.
Jun 9 – 20 · Finish every surface a user expects on top of the engine that already exists.
Jun 23 – Jul 4 · Bring Azure, GitHub, and Slack up to the depth AWS & GCP already have.
Jul 7 – 18 · Make Tara deployable in a customer environment — access control, auditability, alerting.
Post-V1 · Explicitly out of V1 — sequenced after the Discovery module is complete.
Engineering view
The full v1 feature catalogue, mapped to real status derived from the source — not the uniform "WIP" the spec decks show. Sprint column is where it landed (or is targeted). Evidence is the authoritative file.
| Feature | What it does | Sprint | Evidence | Status |
|---|---|---|---|---|
| Agent inventory | One list across every integration; filter by type, account, risk, dormancy. | S1 | pages/AIAgents.tsx | Done |
| Agent detail | Model, tools, knowledge bases, resource reach, invocation history, open findings. | S1 | agents.py | Done |
| Risk findings feed | All issues in one feed; filter by severity, type, date; detail panel. | S4 | pages/ThreatDetection.tsx | Done |
| Focus view | Curated "act on this week" — top agents by risk with highest-severity findings. | S1 | focus.py | Done |
| Posture policies | Named rules with open/resolved lifecycle per violation. | S2 | pages/Policy.tsx | Done |
| Activity reviews | Reviewer workflow over invocation activity — ack, escalate, attach notes. | S2 | activity_reviews.py | Done |
| Identity & access graph | Visual reach map centred on any node — agents, roles, data, humans. | S4 | AccessGraph.tsx | Done |
| Identity mapping | Operator screen mapping directory ↔ cloud identities. | S4 | pages/IdentityMap.tsx | Done |
| DNS / endpoint monitor | Live per-process AI-egress stream; names app + provider. | S3 | dns_events.py | Done |
| Onboarding wizard | Step-by-step integration setup with credential validation + policy generation. | S1 | pages/Setup.tsx | Done |
| Integration & credential mgmt | Rotate/replace credentials without re-onboarding; AES-256-GCM at rest. | S1 | IntegrationDetail.tsx | Done |
| Live log stream | SSE stream of in-flight scan activity — stage, what it's enumerating, why it stalled. | S2 | logs_stream.py | Done |
| Scan job control | On-demand scan, per-stage timings, history. | S1 | pages/Scans.tsx | Done |
| Playbooks | Response workflows per finding. Backend + per-finding drawer live; browse page is a scaffold. | S5 | pages/Playbooks.tsx | Partial |
| Watchlist | Pin agents/roles/principals. Pin backend live; surface page is a scaffold. | S5 | pages/Watchlist.tsx | Partial |
| Change-audit export | Date-ranged CSV of scan-to-scan diffs. | S5 | — | Planned |
| Executive dashboard | Four headline numbers + trend line for leadership. | S5 | — | Planned |
| Dormancy view | Dedicated idle-but-privileged agent surface. | S5 | — | Planned |
| Webhook alerting | Push high-severity findings to Slack/webhook with severity filters. | S7 | — | Planned |
| Feature | What it does | Sprint | Evidence | Status |
|---|---|---|---|---|
| Blast-radius expansion | Resolves an execution role into named buckets, tables, secrets, queues. | S1 | iam_expander.py | Done |
| Privilege-escalation detection | Walks the permission graph ≤3 hops to surface indirect control paths. | S1 | escalation.py | Done |
| Identity & access graph (engine) | Typed graph, single-writer guarantee, locked schema = API. | S0 | worker/graph.py | Done |
| Findings engine | Rule-based + AI-specific pattern detector, severity-tagged. | S1 | worker/findings.py | Done |
| Invocation attribution | Resolves caller identities into human names; 7/30/90-day windows. | S1 | aws/cloudtrail.py | Done |
| Agent classification | Persona-tags workloads (Bedrock, SageMaker, AI-likely Lambda, MCP, CI/CD bot). | S1 | persona_tagger.py | Done |
| Risk scoring | 0–100 score per agent from severity, data reach, frequency, escalation. | S1 | worker/scoring.py | Done |
| Cross-integration correlation | Joins findings across integrations (UC-1…UC-7) on shared keys. | S4 | findings.py::evaluate_global | Done |
| Scan orchestration | Single-flight runner + 15-min janitor; scheduler-driven recurrence. | S1 | worker/scheduler.py | Done |
| Change detection | Scan-to-scan diff. Posture changes via API today; no dedicated diff engine. | S5 | posture.py (partial) | Partial |
| Feature | What it does | Sprint | Evidence | Status |
|---|---|---|---|---|
| Encrypted credential store | AES-256-GCM at rest; sentinel tests block secret leaks. | S0 | shared/core/crypto.py | Done |
| Locked graph contract | Node/edge renames require migration + frontend bump. | S0 | graph_types.py | Done |
| Structured error envelope | Every error returns {error, code} from one registry. | S0 | error_codes.py | Done |
| Read-only by construction | AWS IAM locked read-only; permission gaps → findings, never errors. | S0 | infra/iam-policy.json | Done |
| MCP endpoint | Exposes findings + inventory over MCP for analyst-side agents. | S2 | routers/mcp.py | Done |
| RBAC roles | Admin / Viewer enforcement on routers. Auth scaffold present, not enforced. | S7 | — | Planned |
| Tara self-audit log | Log who triggered/acknowledged/changed what. | S7 | — | Planned |
| Scan-failure notification | Alert on failed scheduled scan (expired cred, revoked perm, rate limit). | S7 | — | Planned |
| Integration | What it surfaces | Sprint | Evidence | Status |
|---|---|---|---|---|
| AWS | Bedrock, AgentCore, SageMaker, Amazon Q, Lambda & ECS, IAM, CloudTrail. | S1 | integrations/aws/ | Done |
| GCP | Vertex AI, Cloud Run/Functions, Cloud Logging. | S2 | integrations/gcp/ | Done |
| Google Workspace | OAuth grants, directory, audit logs — primary shadow-AI surface. | S2 | google_workspace/ | Done |
| Endpoint / DNS sensor | On-host capture, per-process attribution, 29+ provider classification. | S3 | integrations/dns/ | Done |
| Slack | Installed bots/apps, AI-likelihood + scope analysis. Catalog live; connector promotion queued. | S6 | integrations/slack/ | Partial |
| Azure | OpenAI deployments, AI Studio, Container Apps, Entra registrations. | S6 | integrations/azure/ | Partial |
| GitHub | Repos with AI SDK usage, Actions AI env vars, NHIs, OAuth apps. | S6 | integrations/github/ | Partial |
| Microsoft 365 / Entra | App grants/registrations, directory, sign-in logs. | S6 | — | Planned |
| Browser extension | On-device visibility into AI web tools + sessions. | ∞ | — | Planned |
Customer & board view
Two ways to read "coverage": the 7 company stories Tara can tell (real situations a CISO recognises), and the broader catalogue of ~19 AI / agent types a company can have. "Covered locally" is split into what we can demo on built-in data vs. what produces real findings with nothing deployed.
The unowned agent, AI editing your directory, source code leaving a laptop, shadow-AI seen two ways, laptop-to-grant correlation, and the over-shared copilot all run end-to-end. (The 7th — one employee across two clouds — is present but not asserted.)
The only thing that yields real data with no cloud connection is watching a real laptop talk to AI services — everything else needs a real account.
Deploying = connecting read-only access to a customer's AWS and Google Workspace (the two highest-value), plus the laptop sensor.
AWS + Google Workspace light up the unowned-agent, directory-edit, shadow-AI, over-shared-copilot and cross-cloud-identity stories on real data; the laptop sensor completes the two endpoint stories.
Cloud-hosted agents (managed, serverless, container, VM, CI-CD) and data-pipeline agents (queue- / API-gateway-triggered) become discoverable on real infrastructure.
Still not covered even when deployed: employee no-code automations (e.g. Zapier) and AI browser extensions (no connector — need the SaaS / device-management source), anything living purely on a laptop (needs the sensor), and streaming-pipeline agents.
Capture a real person using Cursor / Claude / ChatGPT, show it tied to the app and provider, and write the missing test.
→ our one real-data-without-deploy capability, currently unproven — the biggest credibility gap.Seed a managed agent, an AI serverless function, and an over-privileged role; show real discovery + blast radius + an escalation path + the unowned-agent & over-shared-copilot stories.
→ proves the deploy story on real cloud; lifts built detections from 1 → 3.With AWS already live, this lights up the shadow-AI and one-employee-two-clouds stories on real data.
→ one integration unlocks the cross-cloud "wow."If only two: do #1 and #2 — the real-local wedge and the real-cloud proof.
An AI agent spun up for a one-off project still holds live access to a production database and a customer-data bucket — but the person who built it moved on and no human owns it. It hasn't run in 90 days, so it's invisible on every dashboard. Tara flags it: sensitive access, zero recent activity, no owner — and shows exactly what it can still reach.
A custom GPT wired into Google Workspace to "help with onboarding" can now create and delete employee accounts — and does so automatically, with no human approving each action. Tara catches the moment an AI, not a person, is making admin writes to your identity system, and names the AI and what it changed.
An engineer's local AI coding tool is quietly sending proprietary source code to an AI service that never went through review and never touched corporate SSO — invisible in every cloud log. Tara, on the endpoint, sees the laptop talking to that service, names the app doing it, and names the provider it's sending to.
An employee signed up for an AI assistant and clicked "connect to Google" and "add to Slack" — now it can read their mail, files, and messages, and nobody in security approved it. Tara finds the same tool from two independent angles — the Slack install and the Google OAuth grant — and corroborates them into one confirmed finding.
Tara sees an AI tool running on someone's laptop and sees that same person grant that tool access to corporate data. Each alone is a yellow flag; connected, it's a clear, high-priority story — this person, this tool, this reach into company systems — the kind that becomes an action, not an argument.
A team built an AI "Workspace Copilot" for Finance and gave it broad access to Drive, Gmail, and Calendar — but the way it's wired, people outside Finance can invoke it too, inheriting its access to Finance data. Tara shows the over-sharing: a powerful agent whose set of callers reaches beyond the team it was built for.
Your engineer "Alice" has one identity in AWS and a separate one in Google Workspace — different systems, no obvious link. Attackers and auditors both care about the person, not the account. Tara connects the two, so when you look at blast radius or work an incident you see one human and everything she can reach across both clouds — not two disconnected fragments. (This cross-cloud link is the capability that ties the other six stories together.)