ContactBook a demo

Credential Security

Every credential.Its identity. Its blast radius.

Scanners find strings that look like secrets. Trustivan maps each credential record to the identity that holds it, the owner who answers for it and the resources it can reach, so a reported exposure becomes a prioritized finding instead of a noisy list.

AvailableM3 · Credential Security · M5 exposure
Book a demoExplore Credential Security

Identity ≠ credential · a secret is a relationship, not a string

Credential risks

Exposed. Long-lived. Reused. Leaked.

Four ways a credential becomes a liability — and why each one needs its identity context before it can be fixed without breaking something.

Exposure

Credentials sitting in repositories, pipelines, chat, wikis, tickets and storage where they were never meant to be

Age & reuse

Keys that never rotate and secrets shared across workloads, environments and teams until nobody knows who depends on them

Leakage

Credentials confirmed outside your perimeter — with the identity, the owner and the access they unlock

How it works

From a string in a repository to the identity, owner and data behind it

Finding the credential is the easy part. Knowing what it unlocks, who depends on it and who can safely revoke it is the work.

Identity mapping

Which identity, which resources, which owner

Trustivan resolves which identity a credential belongs to, what that identity can reach and who owns it — so the person who receives the finding can act on it instead of forwarding it.

  • Credential ↔ identity mapping from AWS access key metadata and Kubernetes token secret counts — never a secret value.
  • Blast radius from effective access, not from the scope string printed next to the key.
  • Owner routing from the identity, not from whoever last touched the file.
Available
Long-lived & reused

Age, expiry and sharing as first-class findings

A 600-day access key is a standing invitation. The same credential held by three agents is an incident you will triage three times. Trustivan tracks age, last rotation and expiry per credential, raises rotation-overdue and expiring findings, and flags a credential held by more than one agent.

  • Age and rotation per credential, against a rotation threshold, with the identity and owner that answer for it.
  • Shared credentials raised as a finding against every agent that holds one.
  • Findings, not rotation: Trustivan never rotates, vaults or revokes a credential at a provider.
See Rotation & Expiry
Leak response

When a credential is reported exposed, the finding already knows its identity

Which identity, which owner, which resources — and, where activity has been ingested, whether it was used after the exposure. Trustivan assembles the answer from the graph and proposes remediation for a second person to approve; nothing is revoked or rotated at the provider.

  • Use after exposure from activity submitted through the ingestion API — no connector collects it.
  • Blast radius before anyone acts, from the identity’s effective access.
  • Revoke and rotate proposals are recorded and approved; with no provider executor registered, they are not executed.
See the exposed credential use case

What you get

A credential program that starts from identity

Six views, all reading from the same graph — so a credential finding already knows its identity, its owner and its consequence.

Credential inventory

Credential metadata from each connector mapped to an identity and an owner — never a secret value

Exposure findings

Exposures reported through the ingestion API, matched to the credential and identity they belong to — no scanner ships

Age & rotation status

Credential age, last rotation and expiry per identity, owner and environment

Shared credentials

One credential held by more than one agent, raised as a finding against every holder

Blast radius

The resources a compromised credential unlocks, computed from its identity’s effective access as an upper bound

Used after expiry

An expired credential that ingested activity shows still in use, raised as a finding of its own

Example

An exposed key, traced to production

The difference between a scanner alert and a finding is everything after the word “found”.

CriticalExposedLong-livedProduction

Deployment access key with production write access reported exposed in a public gist

Why
An access key granting write access to production deployment resources was reported exposed outside the organization
What
aws-access-key/AKIA…Q9LX (access key of machine user ci-deployer)
Who
Owner: Web platform team (declared by tag)
Where
Exposure reported through the ingestion API from a public gist · AWS account prod-core
How
Key created 412 days ago and never rotated; activity ingested after the exposure shows it still in use
Blast radius
Write on 14 resources · can assume the production deploy role · effective access, an upper bound
Recommendation
Revoke the key at AWS now, reissue as a short-lived role session scoped to the deploy job
Action
Propose revoke for second-person approval · notify owner · quarantine the identity in the platform
Evidence
Exposure record · access key metadata · ingested activity (30 days)
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

Related capabilities

Credentials are one edge of the graph

Rotation findings remove the surprise, posture weighs the excess access, discovery keeps finding new keys.

All solutions

See every credential mapped to its identity.

See how TRUSTIVAN connects identity, credential, access, agent and action context into one control plane.

Book a demo