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.
Coverage / Identity & credentials
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.
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.
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.
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.
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.
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
Discuss the assessment scope, current capabilities and the control you need with Altari Systems.