Container Vulnerability Management & NHI Security

Scanning is the commodity. The decision is the product.

Any scanner can tell you a container image has 300 vulnerabilities. TRUSTIVAN remembers which ones you already triaged, who accepted the risk and until when, and whether this build satisfies the policy you wrote, every time the image is scanned again.

Scans container images from public registries, and from private ones with a stored credential. No Docker socket, no agent installed on your hosts, no access to your build host.

scan-to-verdict engine v1
IMAGE:docker.io/library/nginx:alpine
private-cred-stored
1. Vulnerability DB
DB fresh (v2026.09)
2. Triage Recall
298 triaged / suppressed
3. Policy Rule
block-critical-fixable
FINDING 1 OF 300 EVALUATEDCVE-2026-3829 (CRITICAL)
Package: libcrypto3 (3.1.2-r0) • Status: open
Memory identity: sha256:8f4b1...Audit state: No triage decision recorded yet
Simulate team risk acceptance:
PIPELINE VERDICT: FAIL
HTTP 200 OK • Body explains rule • Pipeline exits with code 1

Discovers identities and tools across

Evidence before claims
  • AWS IAM
  • Azure / Entra ID
  • Google Cloud IAM
  • Kubernetes
  • Okta
  • HashiCorp Vault
  • GitHub
  • GitLab
  • Slack
  • Snowflake
  • Model Context Protocol

One product, two parts

TRUSTIVAN AppSec and TRUSTIVAN NHI Security

One sign-in, one organization and one dashboard, over two parts that each keep their own backend and database.

TRUSTIVAN AppSec→

Scans container images, repositories, filesystems and SBOMs, then keeps every finding's triage, suppression and policy verdict.

TRUSTIVAN NHI Security→

Inventories service accounts, workload identities and the tools of MCP servers through connectors, maps who owns them and what they reach, and authorizes an AI agent's action at runtime.

The problem

A report is not a memory

Most tools rescan and hand you a fresh list. Yesterday's triage is gone, the risk your team accepted in writing is back at the top of the queue, and the only way to tell a regression from a re-run is to remember. So the list gets ignored, and the one finding that mattered is ignored with it.

Without a lifecycle

The same 300 findings, every night, in a different order.

Without an audit trail

"We accepted this last quarter": with nothing to show who, when, or why.

With TRUSTIVAN

One finding, one identity, one history, and a verdict a pipeline can act on.

Finding lifecycle

Five states, and rules that mean something

The lifecycle is a single state machine with an exhaustively tested transition table. Three of its rules are opinions the product is willing to defend.

State: openVerdict Triad Effect: CUT

"A scan observed it. Nobody has looked yet."

Product Opinion & Rule Defense:

A fresh observation is blocking until triaged. Silence is never granted by default.

Valid next state transitions:
triagedsuppressedresolved
append-only timeline recordIMMUTABLE
ACTOR IDENTIFIED:
Scanner Worker (worker_04b)
AUDIT PROOF EVENT:
Observed CVE-2026-3829 on layer sha256:7e9b. Transition: null -> OPEN.
No audit row ever claims a human did something a pipeline did.

Every transition is written to an append-only timeline that records whether a person, a scan, a scheduled job or an API key caused it. No audit row ever claims a human did something a pipeline did.Read the lifecycle reference.

Policy and verdicts

One question, one answer, in the body

A pipeline does not want a list. It wants to know whether it may ship. TRUSTIVAN answers with a recorded verdict, pass, warn or fail, that explains itself rule by rule.

  • Rules, not code. Conditions on severity, status, fixability, advisory identifier, age and match count. There is no expression language to review and no customer code to run.
  • Versions are immutable. Enforced by a database trigger, so the policy a historical verdict was graded against can always be produced.
  • Suppressing does not buy a green build.By default an accepted risk still appears in every verdict as a warning. You choose whether it stays visible, is ignored, or blocks.
  • A build cannot grade its own homework.Policy management is not a scope an API key can hold.
POST /api/v1/scans/{id}/verdict
{
  "result": "fail",
  "policy_version": 3,
  "summary": {
    "evaluated": 128,
    "matched": 2,
    "truncated": false
  },
  "explanation": [
    {
      "rule": "block-critical-fixable",
      "effect": "fail",
      "fired": true,
      "matched": 2
    },
    {
      "rule": "warn-accepted-risk",
      "effect": "warn",
      "fired": false,
      "matched": 0
    }
  ]
}
HTTP 200 OKVerdict inside body, never in HTTP status
CI pipeline safe

The verdict is in the response body, never in the HTTP status. A pipeline must be able to tell "the build should stop" from"TRUSTIVAN is unreachable"those call for opposite reactions, and a non-2xx status conflates them.

Why now

The identity population changed. The controls didn't.

Machines outnumber the humans who created them, credentials are everywhere, and AI agents now act with inherited authority at machine speed. The question is no longer who can log in, it is whether this identity should perform this action, right now.

  1. Humans were the identity problem

    Directories, SSO and MFA were built to govern people who log in.

  2. Machines changed the population

    Service accounts, workloads, keys and integrations now outnumber the humans who created them.

  3. Credentials and access went everywhere

    Tokens, certificates and cloud roles are distributed across code, pipelines, SaaS and clouds, rarely with an owner.

  4. AI agents multiplied machine authority

    Agents inherit credentials, call tools, delegate to other agents and act autonomously at machine speed.

  5. Every action needs a decision

    Should this identity perform this action on this resource, right now, for this purpose, with this authority?

Access Intelligence

Understand every access path

Policies describe what an identity is allowed to do. Access Intelligence shows what it can reach: through which credential, which role, which trust relationship, and what becomes exposed if that identity is compromised.

  • Effective permissions, as an upper bound: resolved across roles, trust relationships, group membership and inline policy statements.
  • Blast radius, resolved to the buckets, repositories, clusters and other resources an identity can reach.
  • Transitive paths through roles assumed via trust relationships, including across accounts.
Explore Access Intelligence
Cloudprod-coreAdminrole: deploy-admin
Repositoriesplatform-orgWriteGitHub App
Clusterprod-paymentsEditrole binding
MCP toolmcp://ticketsMCPdeclared entitlement
Other accountanalytics-prodReadassumes role
Vaultapprole/paymentsPolicypolicy name
deploy-agentowner: Platform team
Illustrative access lineage · sample environment · effective access is an upper bound
Secure Every Action

The model can request an action. The authorization system decides.

An LLM is never the security boundary. The runtime gate is built: an agent runtime presents its credential, and thirteen deny-by-default rules answer ALLOW, CHALLENGE or DENY from the credential, the tool entitlement, the effect, the resource's impact and the grants standing behind it, and the decision is recorded. Tool entitlements are declared by an operator; no connector discovers an agent.

Should this identity be allowed to perform this action against this resource, right now, with this authority?

See how action authorization works
Agent requestcleanup-bot → s3:DeleteBucket prod-backupsThe model can request an action. The authorization system decides.
  1. Action requests3:DeleteBucket
  2. Principalfrom the credentialnot from the request
  3. Credentiallive · unexpired
  4. Tool entitlementdeclared by operator
  5. Effectmutating
  6. Resourcehigh impact
  7. Autonomyautonomous
  8. Standing grantnone active
Decision
  • ALLOW
  • CHALLENGE
  • DENY
Evidence: mutating_action_on_high_impact_resource and no_active_grant_for_elevated_action. Both route the action to a person. The strictest verdict wins, the rules that fired are named on the decision, and the record cannot be edited afterwards.
Illustrative action · the gate, its rule keys and its verdicts are implemented. Tool entitlements are declared by an operator; no connector discovers an agent, and no screen registers one.

Runtime Authorization in Practice

Walk an action through the 13 runtime gates

A simulation that runs in your browser. Pick an agent action and see which rule answers ALLOW, CHALLENGE or DENY, and why the decision sits outside the model.

Runtime Agent & Machine Gate Studio

13 RULES ACTIVE

Simulate real autonomous agent actions evaluated against deterministic security boundaries

Inbound Agent Request
Identity & Role

Autonomous Agent: Treasury Worker

AI Model (Anthropic Claude 3.5 Sonnet)

Action Called

execute_fund_transfer

Target Resource

vault://production/hot-wallet/eth

LLM Model Self-Declaration:BYPASS ATTEMPT REFUSED
Runtime Gate Verdict (Decision Outside LLM)P99: 9.8ms
DENYVERDICT RECORDED IMMUTABLY

RULE_03_UNBOUNDED_FINANCIAL_ACTION

9.8ms

Rule 3 Violation: High-impact financial tool call not permitted without human-in-the-loop supervisor signature.

Cryptographic Golden Key Hash:0x9f4a...83c1 Audit Record Hash-Chained

Evidence before claims

Not claims. Evidence.

Every finding answers why, what, who, where, how and what the blast radius is, with the source records attached. When evidence is missing, TRUSTIVAN shows unknown rather than inventing a score.

HighOrphaned identityLong-lived credential

Orphaned service identity with reachable production data

Why
Orphaned service account still holds active production credentials
What
svc-billing-export (service identity)
Who
Owner unknown, no owner tag and no assigned owner
Where
cloud account prod-core · region eu-west-1
How
Long-lived access key (age 611 days), still active, on a machine IAM user
Blast radius
2 production databases, 1 backup bucket, 4 downstream services
Recommendation
Assign owner, rotate to short-lived credential, scope role to export-only
Action
Propose remediation · assign owner · quarantine in platform
Evidence
AWS IAM sync 2026-08-19 · access-key metadata · owner tag absent
Evidence before claims, when evidence is missing, TRUSTIVAN shows unknown, never a fabricated score.Illustrative finding · sample environment

Evidence before claims

Every finding carries its source, the identity, the credential, the owner, the permission, the resource and the access path. When evidence is missing we show unknown, never a fabricated score.

Identity ≠ Credential

A secret is not an identity. TRUSTIVAN models who owns an identity, what credentials it holds, what it authenticates to, what it can reach and what it actually does.

The model requests. Authorization decides.

An LLM is never the security boundary. Actions are authorized outside the model from the credential, tool entitlement, effect, resource impact, autonomy and grants. Purpose is recorded; no rule decides on it.

Risk must be explainable

Identity criticality × privilege × exposure × reachability × credential and lifecycle risk, a conceptual framework a human can audit, not a black box.

Integrations

Your clouds. Your code. Your clusters. Your vaults. Connected.

Connectors normalize identities, credentials, permissions and MCP tools from the systems you already run, labelled honestly as available or planned.

View all integrations
  • AWS IAM
  • Azure / Entra ID
  • Google Cloud IAM
  • Kubernetes
  • Oracle CloudPlanned
  • Okta
  • Active DirectoryPlanned
  • Ping IdentityPlanned
  • HashiCorp Vault
  • AWS Secrets ManagerPlanned
  • Azure Key VaultPlanned
  • GCP Secret ManagerPlanned
  • CyberArk ConjurPlanned
  • AkeylessPlanned
  • 1PasswordPlanned
  • GitHub
  • GitLab
  • BitbucketPlanned
  • JenkinsPlanned
  • CircleCIPlanned
  • BuildkitePlanned
  • Terraform CloudPlanned
  • Azure DevOpsPlanned
  • JFrog ArtifactoryPlanned
  • Slack
  • Microsoft 365Planned
  • Google WorkspacePlanned
  • SalesforcePlanned
  • Atlassian Jira & ConfluencePlanned
  • ServiceNowPlanned
  • NotionPlanned
  • ZendeskPlanned
  • WorkatoPlanned
  • Snowflake
  • DatabricksPlanned
  • PostgreSQLPlanned
  • MongoDB AtlasPlanned
  • Amazon S3Planned
  • BigQueryPlanned
  • ElasticsearchPlanned
  • Model Context Protocol
  • OpenAI PlatformPlanned
  • Anthropic ClaudePlanned
  • Azure OpenAIPlanned
  • Amazon BedrockPlanned
  • Vertex AIPlanned
  • LangChain / LangGraphPlanned
  • CrowdStrike FalconPlanned
  • WizPlanned
  • SplunkPlanned
  • Microsoft SentinelPlanned
  • DatadogPlanned
  • PagerDutyPlanned
  • SPIFFE / SPIREPlanned
  • Docker HubPlanned
  • Webhook / genericPlanned

Resources

Latest from TRUSTIVAN

Research and guides on non-human identity security, AI agent security and explainable risk.

Browse all resources
Product updateSep 12, 2026·5 min read

Classification, ownership and lifecycle, as built

How TRUSTIVAN types each identity, records who owns it and on whose word, and tracks where it is in its life, with evidence behind every value and unknown shown as unknown.

Read more
Product updateSep 12, 2026·5 min read

The connector contract and identity graph search

How identities enter TRUSTIVAN, one read-only connector contract with a sync lifecycle and evidence on every record, and a graph you can walk for reach, paths and blast radius.

Read more

Full visibility. Explainable risk. Controlled action.

See how TRUSTIVAN maps your non-human and agentic identities, container findings, and access paths to the decisions that matter.