AI DEFENCEBY ALTARI SYSTEMS
Menu

Coverage / Identity & credentials

Identity and secrets security, across every access boundary.

AI Defence is designed to assess human, service and machine identities alongside the credentials that grant access. The scope connects account posture, privilege, exposed secrets and authentication controls to the systems those identities can reach.

IN DEVELOPMENTExplore the specified scope. See capability availability.

Inventory accounts and their actual authority

The specification covers user, service, privileged, dormant, default and shared accounts. Password-policy weaknesses, MFA coverage, group membership and excessive permissions are included, together with potential privilege-escalation paths. An account’s label is less useful than knowing what it can actually do.

SSH configuration, authorised keys, stale or unknown keys, root login and sudo policy receive explicit attention. Application, database, machine and API identities extend the review beyond interactive users. Access to a deployment system can carry different consequences from access to a single application screen.

Look for credential exposure across the lifecycle

Secrets can appear in environment variables, .env files, configuration, repositories and Git history. CI/CD variables, container images, backups and logs are also in scope, alongside hard-coded passwords, tokens, private keys and certificates.

The assessment includes expired certificates, weak key material, excessive credential scope, reuse and rotation requirements. Evidence should identify the location and consequence of an exposure without needlessly reproducing usable secrets in reports or telemetry. Collector configuration and data-handling controls must be agreed before access is granted.

Plan revocation and rotation as operational changes

Revoking an obsolete key may be straightforward; rotating a credential used by several services may require a sequenced change. The proposal should identify dependent workloads, update paths, approval and verification. Removing a string from a repository does not invalidate the credential or erase its historical exposure.

The intended continuous-monitoring scope includes new SSH keys, privilege and account changes, exposed secrets and weakened authentication configuration. These signals should be reconciled with approved administration and investigated where unexplained. Automated rotation is described only where supported and authorised.

Questions answered

Does deleting a leaked secret from a file fix the exposure?

Not on its own. The affected credential may need revocation or rotation, and its consumers must be updated safely. The relevant repository history, logs or backups may still contain it.

Does the report need to display full secrets?

A useful finding can describe the location, type, scope and evidence of exposure while masking the secret value. Data collection and report access should follow agreed privacy and permission controls.

Start with understanding

What does your environment need to defend?

Discuss the assessment scope, current capabilities and the control you need with Altari Systems.

Talk to Altari