Clyra

Identity and authority

AI coding tools turn credentials into delivery authority.

Non-human identity inventory is necessary. It is not enough. Security also needs to know which AI-assisted workflow can use a credential, what action it can take, which system it can affect, and whether approval or evidence exists.

Last updated: May 12, 2026

AI coding tools create new pressure on non-human identities because agents and workflows often inherit tokens, CI secrets, OAuth grants, cloud keys, package credentials, or developer permissions. The practical question is not only “which credential exists?” It is “which AI-assisted workflow can use this authority to change a real system?”

Why identity inventory is not enough

IAM, PAM, and NHI tools help teams inventory credentials and understand permission scope. That matters. But software delivery risk appears when a credential is connected to a workflow that can write code, run commands, deploy, publish packages, reach a declared tool, or touch cloud paths.

For AI-assisted engineering, security needs a map that joins identity to workflow context: where the path was introduced, what can trigger it, which target it reaches, who owns it, and what evidence pack will exist later.

AI-assisted workflow -> repo / PR -> CI secret -> deploy command -> cloud target -> approval / evidence

Credentials security teams should map

Repository tokens

GitHub tokens, GitLab tokens, personal access tokens, bot tokens, and scoped automation tokens.

CI/CD secrets

Workflow secrets, runner environment variables, package publishing credentials, and deployment keys.

Cloud authority

Cloud keys, OIDC trust paths, assumed roles, workload identity, and CLI permissions reachable from automation.

Tool and MCP access

OAuth grants, MCP server tokens, tool scopes, internal API credentials, and local tool permissions.

Questions to ask before expanding AI coding access

  • Which AI-assisted workflows can reach credentials or CI/CD secrets?
  • Can the workflow write code, modify workflow files, execute scripts, publish artifacts, or deploy?
  • Does the credential have standing authority or just-in-time authority?
  • Can the action reach production, customer data, package registries, cloud infrastructure, or release systems?
  • Who owns the workflow and who approved the authority?
  • What evidence pack would exist during a customer review, audit, or incident investigation?

Why MCP makes the identity question more urgent

MCP gives agents a standard way to declare and reach tools and resources. That is useful, but it also makes scope, consent, and audit clarity more important. The official MCP security guidance discusses confused deputy risk, token passthrough, local server compromise, and scope minimization.

For AppSec and platform teams, the practical control is to avoid treating agent tool reachability as one flat permission. The action path should show which tool, which credential, which scope, which target, and which approval rule apply.

Where Clyra fits

Clyra does not replace NHI, IAM, PAM, or secret scanning. Those tools remain important. Clyra uses identity and credential context as inputs to a software-delivery action-control graph.

The output is an Agent Action BOM: actor or workflow, repo or PR, credential, reachable action, target system, owner, approval rule, and evidence coverage.

Source notes

  • GitHub describes Copilot cloud agent as an autonomous software development agent that can make code changes on a branch and create pull requests. GitHub Docs
  • Claude Code documents fine-grained permissions, allow/ask/deny rules, tool permissions, and hooks. Claude Code Docs
  • MCP security guidance covers confused deputy risk, token passthrough, local server compromise, and scope minimization. MCP Security Best Practices

Map the action path behind the credential.

Start with two to three repos or workflows where AI-assisted engineering is close to CI/CD, tool access, or release paths.

Request assessment