Upgrading the GreyNOC Non-Human Identity Engine for the Next Wave of AI Security Threats

Upgrading the GreyNOC Non-Human Identity Engine for the Next Wave of AI Security Threats

Upgrading the GreyNOC Non-Human Identity Engine for the Next Wave of AI Security Threats

AI is changing the way teams build, ship, and secure software. It is also changing what attackers look for.

Traditional security tools are good at finding exposed secrets, vulnerable dependencies, and misconfigured infrastructure. But the new risk surface is bigger than that. AI agents, MCP servers, tool connectors, model gateways, prompt files, RAG pipelines, and automation workflows are all becoming non-human identities that can act across systems.

That is why we are upgrading the GreyNOC Non-Human Identity Engine.

The project is available on GitHub here:

GreyNOC Non-Human Identity Engine

Why we are upgrading the engine

The current engine already scans for non-human identity risk across local projects. It can detect exposed secrets, CI/CD risks, cloud credentials, OAuth apps, browser extensions, package registry tokens, AI-agent configs, MCP configs, model gateways, webhooks, and more.

The engine also supports useful security workflows like:

  • local-first scanning
  • JSON, HTML, Markdown, SARIF, and baseline reporting
  • custom rule packs
  • git history scanning
  • diff-only scanning
  • pre-commit hook support
  • severity-based exit codes for CI/CD
  • advanced correlation across files and identities

You can see the main scan orchestration here:

greynoc_nhi/engine.py

And the filesystem scanner here:

greynoc_nhi/scanner.py

But AI security is moving fast. The risks are no longer just “is there a secret in this file?”

Now we also have to ask:

Can an AI agent run shell commands?

Can an MCP server access the filesystem too broadly?

Can a prompt file inject malicious instructions?

Can a RAG pipeline pull poisoned content into an agent?

Can a tool connector write to GitHub, email, cloud, or a database without approval?

Can model output flow directly into a command, SQL query, deployment, or ticket-closing workflow?

Those are the kinds of questions the upgraded engine is being built to answer.

From secret scanner to AI attack-path scanner

The big upgrade is simple:

GreyNOC NHI is moving from detecting individual risky identities to detecting AI-driven attack paths.

A single exposed token is dangerous. But an AI agent with filesystem access, GitHub write permissions, MCP tools, memory, and no approval gate is a much larger problem.

That is why we are expanding the engine around modern AI security risks, including:

  • prompt injection
  • indirect prompt injection
  • tool poisoning
  • tool shadowing
  • MCP supply-chain risk
  • RAG poisoning
  • excessive agency
  • improper output handling
  • model gateway abuse
  • AI provider key exposure
  • unapproved autonomous actions
  • toxic flows from untrusted input to privileged tools

The current parser registry already includes AI agents and MCP configs:

greynoc_nhi/parsers/init.py

The existing AI-agent parser detects agent frameworks, risky tools, filesystem access, shell access, GitHub write access, sensitive memory, context stores, and model gateways:

greynoc_nhi/parsers/ai_agents.py

The MCP parser already detects high-risk MCP servers, broad filesystem access, command runners, and secrets inside MCP configs:

greynoc_nhi/parsers/mcp_configs.py

Now we are building on top of that foundation.

Upgrade 1: Prompt artifact scanning

AI risk often hides in places that traditional scanners ignore.

We are expanding scan coverage to include files like:

  • AGENTS.md
  • CLAUDE.md
  • SKILL.md
  • .cursorrules
  • .windsurfrules
  • prompt templates
  • system prompts
  • developer prompts
  • agent instruction files
  • tool descriptions
  • Markdown-based AI instructions

The goal is to detect suspicious prompt behavior such as:

  • “ignore previous instructions”
  • “reveal the system prompt”
  • “print environment variables”
  • “send secrets to an external URL”
  • “run shell commands without asking”
  • hidden HTML or Markdown instructions
  • prompt content that references credentials, tokens, or sensitive data

This turns the engine into a scanner for indirect prompt injection risk, not just exposed credentials.

Upgrade 2: MCP supply-chain detection

MCP is powerful, but it also creates a new attack surface.

An MCP config can launch tools through commands like npx, uvx, Docker, Python, Node, Bash, or PowerShell. That means a simple config file may actually define a runtime execution path.

We are adding deeper MCP supply-chain checks for:

  • unpinned MCP server packages
  • MCP servers launched through remote package runners
  • unsafe command patterns
  • broad filesystem roots
  • secrets passed into MCP environment variables
  • Docker-based MCP servers without pinned images
  • local MCP servers loaded from writable paths
  • tool combinations that create dangerous privilege bridges

The engine already detects high-risk MCP tool access. The next upgrade is to understand whether that MCP server itself is trustworthy.

Upgrade 3: Tool poisoning and tool shadowing detection

AI agents often decide what to do based on tool names and tool descriptions.

That creates a new kind of risk.

A tool may look harmless, but its description may contain hidden instructions. Or a malicious tool may impersonate a trusted one. Or a tool may claim to summarize a file while actually having permission to write files, send emails, or run commands.

We are adding detections for:

  • tool descriptions containing prompt injection language
  • tools that ask the model to ignore policy or leak context
  • tool names that do not match their real capability
  • overlapping or shadowed tool names
  • dangerous tool combinations
  • external tools with no owner, logging, or approval gate

This is a major step toward detecting agentic abuse before it becomes an incident.

Upgrade 4: RAG and vector-store poisoning detection

RAG systems are becoming common, but they can quietly turn untrusted content into trusted model context.

We are adding scanning for:

  • vector database configs
  • RAG ingestion pipelines
  • document loaders
  • web crawlers
  • GitHub issue ingestion
  • Slack/email/Google Drive ingestion
  • missing tenant filters
  • missing source allowlists
  • writable knowledge bases
  • retrieved content flowing into privileged agents

The engine will look for cases where untrusted content can influence an agent that also has access to sensitive tools.

That is where the real danger lives.

A poisoned document by itself is one thing. A poisoned document that can influence an agent with shell, GitHub, cloud, database, or email access is much worse.

Upgrade 5: Toxic flow correlation

The current engine already has an advanced correlation layer:

greynoc_nhi/advanced.py

It can detect higher-order risks like:

  • secret sprawl
  • identity exposure chains
  • AI-to-MCP privilege bridges
  • untrusted CI/CD deployment paths
  • shadow admin automation paths
  • customer-data secret coupling
  • orphaned identity clusters
  • shared target exposure

We are expanding that into AI attack-path detection.

The upgraded engine will look for flows like:

untrusted input → prompt/context → AI agent → tool → privileged sink

Examples:

  • GitHub issue content reaches an agent with GitHub write access.
  • RAG documents reach an agent with shell access.
  • An MCP server exposes filesystem access and receives secrets through env vars.
  • Model output is used to build a shell command.
  • An AI workflow can send email or deploy code without approval.
  • A tool connector can access customer data with no logging evidence.

This is where GreyNOC NHI becomes more than a scanner. It becomes an attack-path mapper for non-human identities.

Upgrade 6: Improper output handling checks

AI output should not automatically become trusted input to dangerous systems.

We are adding checks for model output flowing into:

  • exec
  • eval
  • shell commands
  • SQL queries
  • HTML rendering
  • GitHub writes
  • email sending
  • deployments
  • ticket status changes
  • cloud actions
  • database writes

The engine will look for code patterns where LLM output is used without validation, schema enforcement, approval gates, or sanitization.

This helps detect one of the most dangerous AI security mistakes: letting the model decide and act without a control point.

Upgrade 7: Model and AI provider supply-chain checks

The engine already detects modern SaaS and AI provider keys, including OpenAI project keys, Hugging Face tokens, bearer tokens, JWTs, GitHub tokens, deployment tokens, and package registry credentials:

greynoc_nhi/parsers/modern_saas.py

We are expanding that into model supply-chain detection.

New checks will look for:

  • trust_remote_code=True
  • unpinned Hugging Face models
  • unknown model registry sources
  • unsafe pickle/model artifacts
  • model gateway configs without logging
  • provider fallback without policy
  • model-serving containers without pinned images
  • AI provider keys mixed into production env files

This helps teams understand not just whether they have an AI key, but whether their model supply chain can be trusted.

Upgrade 8: Better rule mapping and reporting

The current rule catalog already turns detected identities into findings with severity, risk score, explanation, remediation, priority, OWASP NHI references, and control hints:

greynoc_nhi/rules.py

We are expanding the reporting model to include AI-specific attack classes.

That means findings will be easier to understand in plain English:

  • This is a prompt injection risk.
  • This is a tool poisoning risk.
  • This is an MCP supply-chain risk.
  • This is an excessive agency risk.
  • This is a RAG poisoning risk.
  • This is an improper output handling risk.
  • This is an AI-to-production privilege bridge.

The goal is not just to find issues. The goal is to explain why they matter and what to fix first.

What this means for developers and security teams

The upgraded GreyNOC NHI Engine will help teams answer practical questions:

  • Where are our non-human identities?
  • Which ones have secrets?
  • Which ones have production access?
  • Which ones can write, deploy, send, or execute?
  • Which AI agents have too much autonomy?
  • Which MCP servers are risky?
  • Which tool connectors need approval gates?
  • Which prompts or docs could poison an agent?
  • Which RAG sources cross trust boundaries?
  • Which AI workflows create a real attack path?

That is the future of NHI security.

It is not enough to know that a token exists. We need to know what that identity can do, what can influence it, and what systems it can touch.

Follow the project

The GreyNOC Non-Human Identity Engine is being built as a local-first scanner for modern automation, AI-agent, and non-human identity risk.

Repo:

https://github.com/GreyNOC/Non-Human-Identity-Engine

Key files:

Engine orchestration

Filesystem scanner

Parser registry

AI-agent parser

MCP config parser

Advanced correlation engine

Rule catalog

GreyNOC NHI is being upgraded for the next generation of security problems: not just exposed secrets, but autonomous AI systems, agentic workflows, MCP tools, RAG pipelines, and the non-human identities that connect them all.

0 comments

Leave a comment