Home Services Insights Speaking About Book a Call

Innowaze Ventures LLC  ·  Cybersecurity Consulting

AI Governance. Identity Security.
Technology Transformation.

Helping organizations navigate cybersecurity, AI adoption, identity governance, and enterprise transformation — with practical strategies that reduce risk and improve business outcomes.

Led by a cybersecurity leader with enterprise experience supporting large-scale IAM, compliance, and security transformation programs.

⚠️
Hidden risks are the real threatMost organizations don't know what's exposed until it's too late
Clarity in 2–3 weeksKnow exactly where you stand — fast
🎯
Senior-level executionIAM, NIST, CMMC, AI Governance — applied practically
10+
Years enterprise experience
IAM
Identity governance & access management
AI
Governance & agent risk advisory
Fixed
Price, always

Most Organizations Don't Realize They're Exposed
Until Something Forces the Issue

Cybersecurity and AI governance problems rarely surface as obvious failures. They show up when a funder asks questions you can't answer, when a contract requires compliance you don't have, or when an AI agent is running with access no one formally approved.

Nonprofits

Protecting Your Mission — and Your Funding

You handle donor data, client records, and often protected health information — without a dedicated security team.

  • Donor PII and payment data exposure
  • HIPAA and 42 CFR Part 2 compliance obligations
  • Federal grant security and reporting requirements
  • Board-level accountability for data protection
  • Volunteer and staff turnover creating access risks
Small Businesses

A Cyber Incident Becomes a Business Problem Fast

You rely on systems, store customer data, and process payments — but security gaps grow as you scale.

  • Ransomware locking access to core systems
  • Customer data breach and legal liability
  • PCI DSS compliance exposure
  • State breach notification requirements
  • Cyber insurance denied due to control gaps
Government Contractors

Compliance Now Directly Impacts Contract Eligibility

Security requirements are no longer optional — they determine whether you can win and keep contracts.

  • CMMC Level 1 & 2 certification readiness
  • NIST SP 800-171 control gaps
  • DFARS compliance requirements
  • System Security Plan (SSP) documentation gaps
  • Loss of contract eligibility due to non-compliance

Three Steps to a Safer, More Governed Organization

01

We assess where you are

In 2–3 weeks, we map your security and governance posture, identify your real risks, and document compliance and AI governance gaps — in plain language your leadership can act on.

02

We build your roadmap

You receive a prioritized action plan — what to fix first, what it costs, and the consequence of each risk left unaddressed. No overwhelming lists. Just clear priorities.

03

We help you execute

From focused one-time projects to ongoing fractional leadership, we support you as deeply as you need. You are never left with a report and no one to call.


What We Do — In Plain Language

Every engagement is designed to address a real, specific risk. Fixed scope. Defined deliverable. Clear outcome.

New Service
01

AI Governance & Agent Risk Advisory

Solves: Ungoverned AI agents and shadow AI proliferation

AI agents are being deployed without identity governance, accountability frameworks, or audit trails. This service establishes the governance layer your AI adoption is missing — before a compliance event forces it.

  • AI governance readiness assessment
  • Agent asset inventory and risk classification
  • AI policy and control framework development
  • Shadow AI discovery and remediation roadmap
  • Agent Risk Governance Matrix™ (ARGM™) deployment
02

Cybersecurity Foundation Assessment

Solves: Operating on assumptions instead of facts

A complete picture of your security posture scored against NIST CSF 2.0 — with a prioritized risk list and 30/60/90-day action roadmap.

  • NIST CSF gap report in plain language
  • Prioritized risk findings
  • Action roadmap with cost estimates
  • Delivered in 2–3 weeks, fixed price
03

Access & Identity Governance Review

Solves: Unauthorized access, insider risk, and identity sprawl

Who in your organization can access sensitive data right now — and should they? Most breaches aren't sophisticated hacks. They're former employees with active accounts and access that was never formally governed.

  • Full user access and identity audit
  • Role-based access design and recommendations
  • Non-human identity inventory (bots, agents, service accounts)
  • Streamlined offboarding and lifecycle process
04

Compliance & Grant Readiness

Solves: Failed audits and lost funding

Funders, federal agencies, and cyber insurers are asking harder questions about security. This service makes sure you can answer them — and prove it on paper before an auditor asks.

  • NIST CSF or CMMC gap assessment
  • Written security policies tailored to your org
  • Compliance documentation package
  • Remediation roadmap with priorities
05

Cyber Program Setup

Solves: No coherent security program

You have tools but no program. Staff don't know what to do in an incident. Policies haven't been updated in years.

  • Written policies and incident response plan
  • Vendor security review process
  • Staff training outline
  • Leadership security scorecard

Client Result

From No Security Program to Audit-Ready in 90 Days

An Atlanta-area education nonprofit serving underserved youth came to us with zero formal security practices — and a federal funder beginning to ask compliance questions they couldn't answer.


Organization size: Under 50 employees
Data handled: Student records, donor PII, federal grants

Before
  • No written security policies
  • 14 former staff with active accounts
  • Student data in open shared drives
  • No incident response plan
  • Funder asking compliance questions
  • Board had zero security visibility
What We Did
  • NIST CSF gap assessment
  • Removed 14 orphaned access accounts
  • Implemented role-based access controls
  • Drafted security policies & IR plan
  • Built quarterly board scorecard
  • Delivered prioritized roadmap
Outcome
  • NIST Tier 1 → Tier 2 in 90 days
  • 14 unauthorized access points closed
  • Funder compliance questionnaire answered
  • First board security briefing delivered
  • Cyber liability insurance approved
  • Staff confidence in data handling improved

Thinking on AI Governance,
Identity Security & Technology Leadership

Practical perspectives for technology and security leaders navigating a rapidly evolving landscape.

AI Agent Governance  ·  Article 1 of 4

The Missing Layer in AI Governance: Identity, Trust, and Accountability

As AI agents become participants in business processes, organizations must establish governance, visibility, and accountability for non-human identities.

Read article →
AI Agent Governance  ·  Article 2 of 4

You Cannot Govern AI You Cannot See: Shadow AI, Visibility, and the Foundation of Trust

Shadow AI is the new Shadow IT. Most organizations have no inventory of their deployed AI agents — and no process for discovering what's already running.

Read article →
The Layered Leader  ·  Part 1 of 5

Before the Title: The Layers That Shape a Leader

Leadership doesn't arrive all at once. It grows in layers — through challenges, relationships, and quiet choices that accumulate long before any title confirms it.

Read article →
The Layered Leader  ·  Part 2 of 5

Quiet Leadership: The Decisions No One Sees

The best leadership is often invisible. The diligence no one applauds. The responsibility no one notices. The decisions made before something breaks.

Read article →
AI Agent Governance  ·  Article 3 of 4

Introducing the ARGM™: A Risk-Based Framework for AI Agent Governance

Not all AI agents deserve the same level of trust. The Agent Risk Governance Matrix™ provides a structured approach to evaluating agents before they are trusted to operate.

Read article →

The Agent Risk
Governance Matrix

As organizations deploy AI agents across their operations, the question is no longer whether governance is needed — it's whether your governance model was built for agents at all.

The ARGM™ is a practical classification and governance framework that maps AI agents by authority level and business impact — giving organizations a clear model for applying the right controls to the right agents, without slowing down adoption.

Read the Framework →
Discuss Your AI Governance
Dimension 1

Agent Authority

What can the agent do? What systems can it access? What actions can it take autonomously?

Dimension 2

Business Impact

What is the consequence of failure, misuse, or compromise? Who is affected?

Dimension 3

Identity & Accountability

Does this agent have a registered owner? Defined purpose? Lifecycle governance?

Dimension 4

Verification & Trust

Is trust continuously re-evaluated? Are behavioral boundaries monitored?


Start Here

Find Your Biggest Risk
Before It Finds You

In 30 minutes, we'll walk through your current setup, identify where you're most exposed, and give you a clear direction on what to fix first.

Most organizations leave this call with 2–3 risks they didn't know they had.

Book a Free 30-Minute Call →
No long sales pitch
No commitment required
Just clarity on where you actually stand

Or reach out directly

victoria@innowaze.org

Request a Free Risk Snapshot

Thank you — we'll be in touch within one business day.

Featured Series

AI Agent Governance

4 articles  +  Practitioner Guide
AI Agent Governance Article 1 of 4  ·  Start here

The Missing Layer in AI Governance: Identity, Trust, and Accountability

As AI agents become participants in business processes, organizations must establish governance, visibility, and accountability for non-human identities — before an audit forces the issue.

Read article →

You Cannot Govern AI You Cannot See

Shadow AI is the new Shadow IT. Most organizations have no inventory of their deployed AI agents — and no process for discovering what's already running.

Read article →

Introducing the ARGM™: A Risk-Based Framework

Not all AI agents deserve the same level of trust. The ARGM™ provides a structured, scoring-based approach to evaluating agents before they are trusted to operate.

Read article →

ARGM™ Practitioner Guide

Score, classify, and govern AI agents. Weighted scoring model, governance gate logic, evidence standards, and interactive scorer.

View guide →

Operationalizing Agent Governance

Agent JML lifecycle, access certifications, PAM for agents, separation of duties, agent-to-agent trust chains, and continuous authorization.

Coming soon

The AI Security Triad: NIST, OWASP, and ARGM™

Three frameworks, three distinct questions. Understanding where each one fits — and where the gaps between them live.

Read article →

ARGM™ Technical Architecture

The weighted formula, blast radius scoring, Uncertainty Penalty, Impact Floor Rule, and gate logic that make ARGM™ an enforcement engine.

Read article →

Topic

Identity Governance

Beyond Passwordless: Mapping OT Credential Governance to the Purdue Model

Passwordless solves Layer 1. Most OT environments need all three layers governed simultaneously — with fundamentally different approaches at each.

Read article →

A Vault Is Not Enough for OT Password Management

Why OT credential management needs human identity, privileged vaulting, and offline-capable edge enforcement — and why one tool never covers all three.

Read article →

Non-Human Identities: The Access Risk Most Organizations Haven't Addressed

Service accounts, bots, and AI agents now outnumber human identities in many organizations — most with no lifecycle governance at all.

Coming soon

Series

The Layered Leader

5 parts  ·  2 published
1

Before the Title

Published

2

Quiet Leadership

Published

3

Seeds Planted

Coming soon

4

Experience vs. Titles

Coming soon

5

Who Rises

Coming soon

Before the Title: The Layers That Shape a Leader

Leadership doesn't arrive all at once. It grows in layers — through challenges, relationships, and quiet choices that accumulate long before any title confirms it.

Read article →

Quiet Leadership: The Decisions No One Sees

The best leadership is often invisible. The diligence no one applauds. The responsibility no one notices. The decisions made before something breaks.

Read article →

The Leaders Who Planted Seeds in Me

Every leader is a product of those who believed in them first.

Coming soon

Why Experience Matters More Than Titles & Who Rises

The final two parts of the series — on what titles don't tell you, and what leadership is ultimately measured by.

Coming soon

Topic

Program & Portfolio Leadership

Why Strong Program Managers Learn to Influence Without Authority

You may be accountable for an outcome without directly managing everyone responsible for delivering it. Strong program managers succeed by creating the conditions that allow people to move together — not by controlling everyone involved.

Read article →

Start with a conversation

If something here resonates with your organization's situation, let's talk.

Book a Free Call →
InsightsAI Agent GovernanceArticle 1

Series: AI Agent Governance  ·  Article 1 of 4

The Missing Layer in AI Governance: Identity, Trust, and Accountability

An AI agent provisioned last quarter is querying your HR system, creating ServiceNow tickets, and sending emails on behalf of your team. Do you know who owns it? Do you know what it is authorized to do? Could you answer those questions in an audit?

Most organizations cannot. And as AI agents become embedded in business operations, that gap is no longer theoretical — it is a governance risk.

This article is the first in a series exploring AI agent governance and introducing the Agent Risk Governance Matrix™ (ARGM™), a framework that emerged from recognizing a pattern repeated across organizations: fast adoption, reactive governance, and mounting visibility gaps that only surface when something goes wrong.


AI is becoming an actor, not just a tool

Throughout history, technology enabled humans to work more efficiently, but humans remained responsible for decisions, actions, and outcomes. That is changing.

AI agents now create tickets, initiate workflows, retrieve information, communicate with stakeholders, and perform tasks that previously required direct human involvement. As AI increasingly acts on behalf of humans, organizations must begin viewing it differently.

AI is no longer simply a tool. In many contexts, it is becoming a participant in business processes — an actor capable of influencing decisions, executing actions, and producing outcomes that carry business risk. And participants require governance.


Trust must be reimagined for AI agents

Historically, organizations established trust through human identities. Controls like passwords, MFA, access reviews, and privileged access management helped verify users — but there was also a layer of trust tied to the human behind the identity.

Organizations could evaluate job function, behavioral patterns, employment status, and insider threat indicators over time. Security programs evolved around the reality that humans have intent, motivations, and observable behavior.

AI agents fundamentally change this model. While an agent may possess an identity, permissions, and system access, it does not possess human intent, judgment, or accountability.

The trust model must evolve — and the key shift is not just adding a step. It is recognizing that for AI agents, trust cannot be a destination. It must be a continuous cycle.

Traditional model — trust as a destination
Identity Authentication Authorization Trust
AI-driven model — trust through continuous verification
Identity Authentication Authorization re-verified each cycle Continuous Verification Trust trust triggers re-verification if behavior changes

Unlike human identities, trust for AI agents cannot be assumed once authentication and authorization occur. Trust must be continuously re-evaluated as context, permissions, integrations, and behavior evolve.

Trust should not be assumed. It should be continuously earned through visibility, monitoring, accountability, and verification. In an AI-driven environment, the principles of Zero Trust become more important, not less.

Never trust. Always verify.


Not all AI agents require the same level of trust

The level of trust required should be proportional to the level of authority granted. An AI agent responsible for drafting routine email communications presents a different risk profile than one responsible for provisioning identities and granting access to enterprise systems. Both may operate autonomously — but the potential impact of failure, misuse, or compromise is not comparable.

An email agent may create communication errors or reputational concerns. An identity provisioning agent may grant inappropriate access, create excessive privileges, violate separation of duties requirements, or introduce compliance risk across multiple systems. Governance models must account not only for whether an agent operates autonomously, but for the authority, access, and potential impact of the actions it performs.


Trust begins with identity

Organizations cannot establish trust in an entity they cannot identify. Every AI agent needs a registered owner, a defined purpose, approved permissions, and lifecycle governance. Without these, you do not have an AI agent — you have an unaccountable actor operating inside your environment.

This is where agent asset management becomes critical. Just as shadow IT allowed unauthorized systems to accumulate over years, shadow AI will allow ungoverned agents and bots to proliferate — invisible to security teams, unaccountable to anyone, and operating with access no one formally approved. You cannot govern what you have not catalogued.


Trust requires verification

Trust is not established because an AI system works. Trust is established because organizations can verify what the system did, why it did it, and who is accountable for the outcome. AI risk is not static. An agent that operates within approved boundaries today may present different risks as integrations expand, data sources evolve, and business processes change.

The question is no longer simply whether an AI agent has been authenticated. The question becomes whether the agent continues to operate within its intended purpose, approved permissions, and expected behavioral boundaries.


What comes next

Organizations spent decades developing trust models for human identities. As AI agents become participants in business processes rather than simply tools, those models must evolve to support a new class of non-human identities.

Identity, accountability, visibility, and verification are not barriers to AI adoption. They are the foundation of trusted AI adoption.

Before your organization deploys its next AI agent, ask a simple question: if that agent were audited tomorrow, could someone explain what it does, what it can access, who owns it, and why it should be trusted?

InsightsAI Agent GovernanceArticle 2

Series: AI Agent Governance  ·  Article 2 of 4

You Cannot Govern AI You Cannot See: Visibility, Shadow AI, and the Foundation of Trust

In identity governance, there is a principle practitioners learn early: you cannot certify access you have not inventoried. Before you can review entitlements, remove excessive privileges, or hold anyone accountable for what a user can do — you first have to know what exists.

Organizations spent years learning this lesson the hard way through Shadow IT — ungoverned systems accumulating quietly in the background while security teams governed only what they could see. By the time the audit happened, the inventory was already wrong.

AI adoption is about to teach the same lesson again. And most organizations are not ready for it.

Much of the conversation around AI governance focuses on trust — how to establish it, verify it, and maintain it over time. That conversation is important. But it skips a harder problem that comes first. You cannot establish trust in AI you cannot see. And right now, most organizations cannot see all of the AI operating inside their environments.


Shadow IT introduced ungoverned systems. Shadow AI introduces ungoverned actors.

The distinction matters more than it might seem. An ungoverned system — a server no one documented, a SaaS tool IT didn't approve — creates risk through what it stores and what vulnerabilities it introduces. An ungoverned AI agent is something different. It retrieves information. It generates outputs. It initiates workflows. It sends communications. It influences decisions. It acts.

When an employee connects an AI tool to company documentation, a customer platform, or an internal workflow, they are often solving a real problem. The tool works. Productivity improves. Nobody flags it. But the questions that matter for governance remain unanswered: Was it approved? What data can it reach? Does anyone know it exists? Is anyone monitoring what it does? Who is accountable if something goes wrong?

The risk is not that employees are using AI. The risk is that organizations may not have visibility into what AI is accessing, what it is doing, or what outcomes it is producing — until something surfaces that visibility the hard way.

Shadow AI will not announce itself. It will accumulate the same way Shadow IT did — one tool at a time, one workflow at a time, one well-intentioned productivity improvement at a time. The reason this matters is that visibility is not simply a technology problem. It is an identity problem.


The visibility problem is an identity problem

Every AI agent operating in an enterprise environment requires an owner, a defined scope of permissions, and a lifecycle — the same governance infrastructure organizations already apply to human identities. The same question IAM teams ask about human identities applies directly to AI agents: Does this identity still need the access it has? Is it operating within its approved scope? Has anything changed about its risk profile since the last review?

Most organizations have not extended that thinking to non-human identities yet. They have sophisticated IGA programs governing human access — joiner-mover-leaver workflows, access certifications, privileged access controls — and almost nothing equivalent for the AI agents operating alongside those humans. That asymmetry is the gap. And it is widening every quarter as AI adoption accelerates.


Ownership aligned to function, not individuals

One of the questions that surfaces quickly when organizations try to govern AI agents is: who owns this? The instinct is to assign ownership to the person who created or deployed the agent. That model breaks down fast. Employees leave. Teams reorganize. The person who built the automation is now in a different role, and the agent keeps running — unreviewed, with permissions no one has looked at since the day it was provisioned.

A stronger governance model ties ownership to business function, not to individuals. The agent that supports the HR onboarding workflow is owned by HR. The agent that queries the finance system is owned by Finance. When the person who built it moves on, ownership transfers with the function — not with the employee. This is not a new concept in identity governance. We apply it to service accounts, shared mailboxes, and system identities already. The principle is the same. The application to AI agents is overdue.


Data sensitivity determines what trust is even possible

Not all AI usage carries the same risk. An agent summarizing internal meeting notes operates with limited data sensitivity. Governance can be lighter. Trust can be established with reasonable controls. An agent querying regulated customer data, financial records, or healthcare information is a categorically different governance problem. The governance obligation scales with the sensitivity — and the trust ceiling rises accordingly.

Organizations that skip data classification are not just taking a compliance risk. They are operating agents at a trust level the underlying data sensitivity does not support.


Visibility is not a one-time exercise

In identity governance, access certifications exist because the state of access at provisioning is not the state of access six months later. Roles change. Permissions accumulate. Business needs evolve. The same decay happens with AI agents. An agent that operated within appropriate boundaries at deployment may look very different six months later — new integrations, expanded data access, changed business processes, shifted ownership.

Trust requires continuous validation. Visibility is not established once — it is maintained or it is lost.


What comes next

Establishing visibility is the first problem. But once organizations understand what AI systems exist, a second and harder question emerges. Not every AI agent requires the same level of oversight. The question becomes: how do you determine which agents require the most scrutiny? What factors drive that determination? And how do you build a governance model that is proportional to risk rather than uniform across every agent in the environment?

That is the problem the Agent Risk Governance Matrix™ (ARGM™) is designed to solve. Visibility tells you what exists. The ARGM™ tells you what to do about it.

InsightsAI Agent GovernanceArticle 3

Series: AI Agent Governance  ·  Article 3 of 4

Introducing the ARGM™: A Risk-Based Framework for AI Agent Governance

Most organizations deploying AI agents are asking the wrong questions first. Can we deploy the agent? Does it work? Does it create value? Those are reasonable questions — but they are deployment questions, not governance questions. The harder questions come after, and often too late.

How much authority does this agent have? What is the impact if it fails or is manipulated? How much oversight does it require? Who is accountable when something goes wrong?

In the first article, I argued that trust for AI agents must be continuously verified — not assumed. In the second, I argued that organizations cannot establish trust in AI they cannot see. Both pointed toward the same gap: most organizations lack a consistent, risk-based approach to determining how much governance any given AI agent actually requires. That is the problem the Agent Risk Governance Matrix™ (ARGM™) is designed to solve.

Not all AI agents deserve the same level of trust. If trust should be proportional to risk, governance must be too. The ARGM™ evaluates agents across two dimensions: inherent risk — what the agent is capable of — and governance posture — whether current controls are adequate for that risk.

The ARGM™ is a governance classification framework — specifically, an AI RMF profile for agents, designed to be tuned to organizational risk tolerance, regulatory environment, and business context rather than applied as a universal standard.


Governance should be proportional to risk — not uniform

A meeting summarization agent and an identity provisioning agent are both "AI agents" — but they are not the same governance problem. One summarizes what was said. The other determines who gets access to what. The ARGM™ addresses this by evaluating agents across seven dimensions and producing two separate outputs: an inherent risk score that determines the base governance tier, and a governance posture assessment that confirms whether existing controls are adequate — or flags where they are not.


Two scores, not one

The first five pillars measure inherent risk: what this agent is capable of doing, the access it holds, the authority it exercises, how often it acts, and what data it touches. A critical-impact autonomous agent with privileged access scores high on inherent risk whether your logging is excellent or nonexistent.

Pillars six and seven measure governance posture: whether accountability is clearly defined and whether the agent's activity can be monitored, audited, and reconstructed. Strong posture does not reduce inherent risk — it confirms that controls are appropriate for the risk level.

Strong governance does not make a dangerous agent less dangerous. It makes the danger manageable — but only if the controls match the risk.

Configuration-level assessment only. The same AI product can score very differently depending on how it is deployed. Always score the specific configuration in use — not the product in general. If you are unsure how an agent is configured, that uncertainty is itself a governance signal.


The seven pillars

Pillar 1 · Inherent risk

Impact

What is the worst-case outcome if this agent fails, produces a wrong output, or is compromised? An agent that drafts meeting notes and gets one wrong is a nuisance. An agent that provisions identities incorrectly is a security and compliance event. Recoverability matters: irreversible consequences at any scale anchor the impact score toward the higher end.

Pillar 2 · Inherent risk

Privileges & Access

What can this agent reach, read, write, or execute? Access scope is a primary driver of risk. Access includes not only system permissions but also input channels that can influence behavior — the ability to accept external inputs or user-supplied prompts is itself an attack surface.

Pillar 3 · Inherent risk

Functional Authority

Does this agent inform, recommend, execute, or act autonomously? Authority often matters more than intelligence. A human approval step that exists in name but is never meaningfully exercised is not a governance control — it is approval theater.

Pillar 4 · Inherent risk

Execution Frequency

How often does this agent act? Frequency increases exposure to failure — not the severity of any individual failure. Always read frequency alongside Impact and Functional Authority.

Pillar 5 · Inherent risk

Data Sensitivity

What type of information does this agent access, process, or produce? Sensitivity determines the ceiling on how much trust can reasonably be established at all. Organizations that skip data classification are operating agents at a trust level the underlying data sensitivity does not support.


Governance posture: the second assessment

Pillar 6 · Governance posture

Accountability

Who owns this agent, approved it, and answers when something goes wrong? Ownership should distinguish business accountability, technical administration, and security oversight as distinct roles. A named owner who cannot stop the agent is not an accountable owner. Score 1 if accountability is strong. Score 4 if absent.

Pillar 7 · Governance posture

Visibility

Can this agent's activity be monitored, its decisions reconstructed, and its behavior verified over time? Logs that exist but are never reviewed do not constitute visibility. They constitute documentation theater. Score 1 if visibility is strong. Score 4 if absent.


Governance tiers

TierScoreProfile
Tier 15–8Low risk. Minimal access, no autonomous action.
Tier 29–12Moderate risk. Write access or regular execution. Formal governance required.
Tier 313–16Elevated risk. Sensitive data, autonomous capability. Continuous monitoring required.
Tier 417–20Critical risk. Privileged access, autonomous execution. Executive accountability required.

Two automatic overrides apply: if Impact scores 4, the agent is classified at Tier 4 regardless of composite score. If both Impact and Privileges score 4, no lower-tier classification is valid. High-consequence, high-access agents do not average down.


What comes next

This article introduces the ARGM™ framework. The companion practitioner guide goes deeper: the weighted scoring model, pillar-by-pillar rubric, evidence standards, governance gate logic, operational templates, and the full interactive scoring tool.

If your organization is deploying AI agents today, start with one question: if that agent were audited tomorrow, could you explain what it does, what it can access, who owns it, and why it should be trusted? If the answer is no — that is where governance begins.

InsightsAI GovernanceThe AI Security Triad

AI Agent Governance  ·  Framework Analysis

The AI Security Triad: Why NIST, OWASP, and ARGM™ Answer Three Different Questions

If your organization is deploying AI agents today, ask yourself one question: if that agent were audited tomorrow, could you explain what it does, what it can access, who owns it, and why it should be trusted?

Most organizations cannot. And many are operating under a false sense of coverage — believing that because they align with established frameworks, their AI agents are governed. The reality is more complicated.

Two frameworks come up most often when enterprise security teams talk about AI risk: the NIST Artificial Intelligence Risk Management Framework (AI RMF) and the OWASP AI Exchange. Both are credible, widely adopted, and genuinely useful. But neither was designed to answer the operational governance question that matters most for autonomous AI agents: what is this agent permitted to do, who is accountable for it, and what happens if those permissions are wrong?

That is the gap the Agent Risk Governance Matrix™ (ARGM™) was designed to address — not as a replacement for NIST or OWASP, but as the enforcement layer that sits between organizational policy and application security.


Three frameworks, three distinct questions

Understanding how these frameworks relate requires being precise about what each one actually does.

The NIST AI RMF, published in 2023 and updated in 2024 with the AI RMF 2.0 draft, is an organizational governance framework. Its four core functions — Govern, Map, Measure, and Manage — give leadership a vocabulary and process structure for thinking about AI risk at the enterprise level. It is intentionally broad, voluntary, and principle-based. NIST itself describes it as a resource for organizations "to better manage risks to individuals, organizations, and society associated with artificial intelligence." It does not prescribe specific controls for specific agent configurations. It was not designed to.

The OWASP AI Exchange and the OWASP Top 10 for LLM Applications address a different layer entirely: application security. OWASP identifies technical vulnerabilities in AI systems — prompt injection, training data poisoning, sensitive information disclosure, model denial of service — and provides engineering guidance for hardening those systems against external exploitation. It helps developers build AI applications that are structurally resistant to attack. What it does not evaluate is what permissions an agent has been granted, what it is authorized to do autonomously, or whether that authority is proportionate to the risk it carries.

The distinction that matters: NIST asks whether your organization has a responsible process for AI overall. OWASP asks whether your AI application is secure against external attackers. ARGM™ asks whether the specific configuration of this specific agent — its permissions, authority, data access, and oversight — is appropriate for the risk it represents.

These are not competing questions. They are sequential ones. And the third question, the one about operational configuration and governance at the agent level, is the one most organizations are not answering systematically.


The configuration gap OWASP does not close

Consider a concrete example. An AI coding assistant deployed with suggestion-only, read access presents a fundamentally different governance problem than the same product deployed with auto-push write privileges to a production codebase. From a vulnerability standpoint — the question OWASP is designed to answer — these two deployments may be identical. The same prompt injection risks apply. The same hardening guidance is relevant.

But from an operational governance standpoint, they are not the same problem at all. One agent makes suggestions a human accepts or rejects. The other executes changes autonomously on production systems. The blast radius — the scope and potential irreversibility of impact if something goes wrong — is categorically different.

ARGM™ was built around this insight. It treats autonomous AI agents as non-human identities, extending the same governance logic that mature identity governance programs apply to service accounts and privileged access to the AI agents now operating alongside human users. The question is not whether the agent is secure against external attack. The question is whether the access and authority it has been granted is proportionate to the risk it carries — and whether the controls around it are adequate for that risk tier.


The operationalization gap NIST does not close

The NIST AI RMF is a well-constructed framework, and the convergence of industry practice around it reflects that. But principle-based frameworks have a known limitation: they require translation into operational controls to be enforceable. NIST's Govern function calls for accountability structures. Its Measure function calls for evaluation processes. But it does not specify what accountability looks like for an agent with write access to a regulated database, or what measurement cadence is appropriate for an agent executing thousands of transactions per day.

An organization can complete a NIST AI RMF alignment exercise and still deploy agents with no registered owner, no defined permission scope, and no monitoring. The framework provides the vocabulary. It does not enforce the answer.

This is not a criticism of NIST. It is a feature of how the framework was designed. Voluntary, principle-based guidance is appropriate for driving organizational culture and broad governance maturity. It is not designed to be a deployment gate for individual agent configurations.

The convergence of independent frameworks around similar governance dimensions is meaningful. When OWASP, NIST, and emerging practitioner frameworks all point toward the same underlying problem — that AI agents require identity governance, accountability structures, and proportional controls — it reflects genuine consensus about where the risk lies. ARGM™ is one practitioner response to that consensus, focused specifically on the configuration and deployment layer.


How the three frameworks fit together

The most useful way to think about these frameworks is as a stack, each operating at a different altitude.

NIST AI RMF operates at the organizational level — setting policy, governance culture, and process accountability for AI risk across the enterprise. It is the foundation of an organization's AI governance posture and the framework most appropriate for board-level and executive conversations.

OWASP operates at the application level — hardening AI systems against external exploitation and technical vulnerabilities. It is the framework most relevant for engineering teams building or evaluating AI products.

ARGM™ operates at the configuration level — evaluating specific agent deployments against a consistent risk model, producing a governance tier, and enforcing deployment gates based on whether controls are adequate for the risk tier assigned. It is the framework most relevant for security architects, IAM teams, and risk directors making deployment decisions about specific agents in specific environments.

The three are not interchangeable, and adopting any one of them does not substitute for the others. An organization with strong NIST alignment and rigorous OWASP practices still needs a consistent method for answering the configuration-level governance question for each agent it deploys. That is the question ARGM™ was designed to answer.


The question worth asking before the next deployment

As AI agent adoption accelerates, the governance gap between what organizations are deploying and what they can actually account for is widening. The frameworks exist. The vocabulary exists. What most organizations are still building is the operational discipline to apply governance consistently at the agent level — before deployment, not after an incident.

If that agent were audited tomorrow, could you explain what it does, what it can access, who owns it, and why it should be trusted?

If the answer is no — that is where governance begins.

Sources & References

NIST AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, January 2023. nist.gov/artificial-intelligence

OWASP Top 10 for Large Language Model Applications, v2.0. OWASP Foundation, 2025. owasp.org/www-project-top-10-for-large-language-model-applications

OWASP AI Exchange. OWASP Foundation, 2025. owaspai.org

Galloway, V. "The Missing Layer in AI Governance: Identity, Trust, and Accountability." Innowaze Ventures, 2026.

InsightsAI GovernanceARGM™ Technical Architecture

AI Agent Governance  ·  Technical Deep Dive

ARGM™ Technical Architecture: How a Governance Framework Becomes an Enforcement Engine

Governance frameworks are only as useful as their operational specificity. A framework that identifies risk categories without a consistent method for scoring, classifying, and enforcing decisions based on those categories produces documentation — not governance. The Agent Risk Governance Matrix™ was designed from the outset to be an enforcement engine, not a checklist.

This article addresses the technical architecture of ARGM™: the weighted scoring model, the mathematical modifiers, the floor rule, and the gate logic that converts a risk score into a mandatory deployment decision. It is written for security architects, IAM practitioners, and risk directors implementing agent governance programs rather than evaluating frameworks at a policy level.


Why quantitative scoring matters for agent governance

Qualitative risk frameworks — those that classify risk as High, Medium, or Low based on expert judgment — have a well-documented limitation: inter-rater reliability. Two practitioners evaluating the same agent against the same qualitative criteria will frequently produce different classifications, particularly at the boundaries between tiers. For agent governance programs operating at scale, that inconsistency becomes operationally significant. Deployment decisions that should be deterministic become negotiable.

ARGM™ uses a weighted quantitative formula as its primary scoring mechanism, with mathematical modifiers applied to adjust for factors that simple pillar scores do not capture. The intent is not to eliminate practitioner judgment — it is to make that judgment auditable and consistent.


The two-dimension structure

ARGM™ produces two separate outputs, not one composite score. The distinction is architecturally important.

Inherent risk is assessed across five pillars: Impact, Privileges and Access, Functional Authority, Execution Frequency, and Data Sensitivity. These pillars measure what this agent is capable of — independently of what controls are in place. An agent with critical impact capability and privileged access to regulated data scores high on inherent risk whether it has excellent logging or none at all. Inherent risk determines the base governance tier.

Governance posture is assessed across two pillars: Accountability and Visibility. These measure whether controls are adequate for the inherent risk tier. Strong posture confirms adequacy. Weak posture — specifically, scoring 3 or 4 on either posture pillar — triggers tier escalation or a deployment block, depending on the agent's functional authority tier.

The separation of inherent risk from governance posture matters because it prevents a common failure mode: using the existence of controls to justify underclassifying risk. An agent does not become less dangerous because someone created a monitoring policy. It becomes manageable — but only if the controls are actually adequate for the risk tier. ARGM™ scores these independently and combines them deliberately.


Blast radius weighting

The five inherent risk pillars are not equally weighted. ARGM™ anchors the formula on the two dimensions most predictive of operational impact when governance fails:

Impact (30%) — the severity and reversibility of worst-case outcomes if the agent fails, produces incorrect outputs, or is compromised. Recoverability is scored as a modifier: agents whose actions are irreversible receive a penalty applied to the impact score, because the governance burden on an irreversible action is categorically higher than on one that can be rolled back.

Privileges and Access (25%) — the scope of what the agent can reach, read, write, or execute. This pillar explicitly includes input channels as part of the access surface: an agent that accepts external or user-supplied prompts has a larger effective access scope than its permission set alone suggests, because those inputs can influence its behavior in ways the permission model does not constrain.

The remaining three pillars — Functional Authority, Execution Frequency, and Data Sensitivity — are weighted at 20%, 10%, and 15% respectively. Execution Frequency carries the lightest weight because frequency modifies exposure without changing the severity of any individual action. A meeting summarization agent that runs ten million times is not inherently more dangerous than an identity provisioning agent that runs once — frequency matters, but it does not determine the governance tier independently.


The Uncertainty Penalty

One of the ARGM™ modifiers with no direct equivalent in other frameworks is the Uncertainty Penalty. When a practitioner cannot determine how an agent is actually configured — what data it accesses, what its true permission scope is, or how its outputs propagate — ARGM™ applies a score penalty rather than allowing the uncertainty to resolve in the agent's favor.

This design choice reflects a principle that practitioners in mature identity governance programs will recognize: when access scope is unknown, the appropriate governance response is not to assume minimal access. It is to treat the unknown as a risk signal and govern accordingly until the scope is established. An agent that cannot be inventoried accurately cannot be governed accurately. The Uncertainty Penalty makes that gap visible in the score rather than hiding it.


The Impact Floor Rule

The most important structural rule in ARGM™ is the Impact Floor Rule: if an agent's Impact score reaches the critical threshold, its governance tier cannot fall below Tier 4 regardless of its composite inherent risk score, and regardless of governance posture.

This rule exists because of a failure mode that appears in risk frameworks that rely exclusively on composite scoring: mitigating controls can produce a lower composite score even when the underlying risk has not changed. An agent with critical impact capability — one that can, under plausible failure conditions, produce irreversible harm at significant scale — does not become a Tier 2 governance problem because it has excellent logging and a named owner. The capability exists. The governance obligation follows from the capability, not from the control environment.

The Impact Floor Rule prevents that outcome. It also applies when both Impact and Privileges reach the critical threshold simultaneously: under that condition, no combination of secondary mitigations can produce a valid lower-tier classification. These agents require Tier 4 governance — independent assessment, executive-level accountability, a tested kill switch, and quarterly recertification — as a floor, not a ceiling.


Gate logic and deployment decisions

The final output of an ARGM™ assessment is not a score. It is a deployment decision: Pass, Escalate, or Block.

Pass means the agent's inherent risk tier is supported by adequate governance posture and it meets the control requirements for its tier. Standard deployment proceeds under the assigned tier controls.

Escalate means the assessment has identified conditions that require review before deployment can proceed — typically, governance posture scores that are inconsistent with the inherent risk tier, or edge cases in the pillar assessments that require senior practitioner judgment. Escalation is not a rejection; it is a mandatory review gate.

Block is an automated production block: deployment cannot proceed until specific conditions are remediated. Block conditions include governance posture scores of 3 or 4 on execution-capable agents above Tier 1, missing accountability structures for Tier 3 or Tier 4 agents, and any configuration that triggers the Impact Floor Rule without the Tier 4 controls in place.

The gate logic is deterministic. The same assessment inputs produce the same gate outcome every time. That determinism is what makes ARGM™ an enforcement mechanism rather than an advisory framework — and it is what makes ARGM™ assessments auditable, because the deployment decision follows from the scoring record in a way that can be reconstructed and reviewed.


Relationship to NIST AI RMF control families

ARGM™ was designed to be compatible with NIST AI RMF rather than to compete with it. For organizations using NIST as their policy foundation, ARGM™ functions as the operationalization layer for agent-specific deployments.

NIST's Govern function maps to ARGM™'s accountability pillar and tier-level control requirements — translating the policy obligation for AI accountability into specific ownership structures for each agent tier. NIST's Map function maps to the inherent risk assessment — the five-pillar scoring that establishes what this agent is and what it is capable of. NIST's Measure function maps to the governance posture assessment and the recertification cadence — the ongoing verification that controls remain adequate as the agent and its environment evolve. NIST's Manage function maps to the gate logic and tier-level remediation requirements — the operational response when an agent's risk tier changes or posture degrades.

Organizations that have invested in NIST AI RMF alignment do not need to discard that work to adopt ARGM™. They need to extend it down to the configuration level — and that is precisely the layer ARGM™ was built to address.

Sources & References

NIST AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, January 2023. nist.gov/artificial-intelligence

NIST AI RMF Playbook. National Institute of Standards and Technology, 2023. airc.nist.gov/airmf-resources/playbook

OWASP Top 10 for Large Language Model Applications, v2.0. OWASP Foundation, 2025.

OWASP AI Exchange. OWASP Foundation, 2025. owaspai.org

Shetty, A. et al. "AIVSS-Agentic: Vulnerability Scoring for AI Agent Systems." Presented at RSA Conference 2026.

Galloway, V. "Introducing the ARGM™: A Risk-Based Framework for AI Agent Governance." Innowaze Ventures, 2026.

InsightsIdentity GovernanceOT Credential Architecture

Identity Governance  ·  OT / ICS Security

Beyond Passwordless: A Three-Layer Architecture for OT Credential Governance

The conversation around passwordless authentication is long overdue — and it is moving in the right direction. But for organizations operating industrial control systems, passwordless is not a destination. It is a Layer 1 solution being applied to a three-layer problem. The industry is talking about pieces of this — passwordless at the front end, PAM in the middle, OT edge access at the far end — but too often as separate conversations rather than one integrated credential-governance architecture.

OT credential governance is one of the most complex, underserved problems in enterprise security. Not because the technology doesn't exist. Because the environment doesn't cooperate. PLCs running on unsupported operating systems. Hardcoded vendor credentials baked into firmware. Protocols built for reliability, not authentication. Devices with 20-year lifecycles that cannot be patched without safety recertifications and production shutdowns. Modern identity governance was built for a world where every endpoint can participate in a directory. OT environments are full of endpoints that cannot.

What the field needs — and largely does not have — is a clear architectural framework for governing credentials across all three layers of an OT environment simultaneously, with different approaches at each layer, and an honest account of what is and is not achievable at the bottom.


Why this problem is getting more urgent, not less

For decades, the complexity of OT environments provided a thin layer of security by obscurity. Proprietary protocols, physical isolation, and the sheer operational knowledge required to interact with industrial systems made them difficult targets. That era is over.

Adversaries are becoming more specialized in industrial environments. Dragos now tracks 26 threat groups specifically targeting OT environments — 11 were active in 2025 and three new groups were identified during the year. IBM's 2026 X-Force reporting identified manufacturing as the most targeted industry, accounting for 27.7% of cybersecurity incidents in 2025.

The SANS State of ICS/OT Security 2025 report adds a sobering data point: only about one in eight organizations have full visibility across the ICS Cyber Kill Chain. Monitoring is strongest at the enterprise level — Purdue Level 3 — and drops sharply at the controller and field device layers — Levels 1 and 2. That is precisely where the most consequential systems live. And it is precisely where credential governance is most difficult and most neglected.

The air gap is gone. The complexity that once protected OT environments is now a liability — it slows defenders while adversaries have professionalized their approach to industrial targets. Organizations that govern only what they can see from the enterprise layer are leaving the bottom two-thirds of their OT credential surface unaddressed.


The Purdue Model as a credential governance map

The Purdue Enterprise Reference Architecture remains the most widely used model for understanding OT network segmentation. It divides industrial environments into zones — from the enterprise network at the top through supervisory systems, control systems, and field devices at the bottom. Most security investment follows the same hierarchy: strong at the top, thin in the middle, effectively absent at the bottom.

The three-layer credential framework maps directly to the Purdue Model, but reframes it around a governance question rather than a network segmentation question. The question is not just where are these systems — it is what credential governance is actually achievable at each layer, and what compensating controls are necessary where modern authentication cannot reach.


Layer 1: The enterprise and SCADA boundary

Note: In this article, "Layer 1, 2, and 3" refer to credential-governance layers mapped against the Purdue Model — not as a replacement for Purdue Levels themselves.

Layer 1 covers the enterprise network, historian servers, SCADA workstations, and the systems operating at Purdue Levels 3 and above. These systems run modern operating systems, participate in Active Directory, and can support the full range of PAM capabilities — vaulting, just-in-time access, session recording, credential rotation, and MFA.

This is the layer where enterprise PAM platforms — CyberArk, BeyondTrust, Delinea — operate most naturally. Privileged credentials are stored in a hardened vault, retrieved through a proxy that brokers the session without exposing the credential to the requester, rotated automatically after use, and recorded for audit. Vendor and remote access sessions are time-boxed, logged, and subject to approval workflows. Break-glass procedures exist for emergency access when standard channels are unavailable.

This is also the layer where passwordless authentication is most achievable. FIDO2-based authentication, certificate-based access, and just-in-time privilege elevation all function well at Layer 1. Organizations that have modernized their enterprise PAM program and still believe their OT credential governance is adequate have almost certainly stopped here.

They have not. Layer 1 is the table stakes — necessary but insufficient.


Layer 2: The control and HMI layer

Layer 2 covers Human Machine Interfaces (HMIs), engineering workstations, data historians, and the systems operating at Purdue Levels 2 and 3. These systems sit closer to the physical process. Some run modern operating systems and can participate in a directory. Many run legacy Windows versions — Windows 7, Windows XP — that are no longer supported but cannot be replaced without extensive validation, vendor certification, and operational risk assessment.

This is the layer where OT-aware PAM capabilities become essential. Standard enterprise PAM connectors do not always speak the protocols that Layer 2 systems use. Credential rotation that works cleanly on a Windows Server can disrupt an HMI configuration that expects a specific static credential. Session recording that captures keystrokes on an enterprise workstation may not capture the engineering commands sent through a proprietary control interface.

Governance at Layer 2 requires OT-specific connectors and configuration, a deliberate credential inventory that distinguishes between credentials that can be rotated and those that cannot without operational impact, and a clear policy for how privileged access to these systems is requested, approved, session-recorded, and reviewed. Vendor access — the remote sessions that OEM engineers use to maintain control systems — is one of the highest-risk credential use cases at this layer and one of the most frequently unmanaged.

More than 80% of OT/ICS incidents started with an IT system compromise attributed to increased interconnectivity, according to Waterfall Security. Layer 2 is where that lateral movement from IT to OT happens. It is also where credential governance most commonly stops being enforced.


Layer 3: The field device and firmware layer

Layer 3 is the hard layer. It covers PLCs, RTUs, sensors, actuators, and the field devices operating at Purdue Levels 0 and 1. These are the systems that interface directly with physical processes — opening valves, adjusting pressure, controlling motor speed, managing safety interlocks. A credential compromise at this layer does not produce a data breach. It produces a physical consequence.

And these are also the systems that modern identity governance was not designed for. Some run on embedded firmware with no support for directory integration, certificate-based authentication, or PAM connectors. Some rely on static, default, vendor-managed, or difficult-to-rotate credentials — especially where firmware, certification, protocol, or operational dependencies limit normal credential lifecycle management. Many run protocols — Modbus, DNP3, Profinet — that were designed for reliability and determinism, not authentication. In some configurations, any user on the network can issue commands to the physical hardware.

Modern identity governance often cannot be enforced directly on these devices. What is achievable is a set of compensating controls that create governance around the devices rather than on them:

Network segmentation and unidirectional gateways — restricting which systems can reach Layer 3 devices at the network level, and using data diodes or unidirectional security gateways to ensure that communication flows can be monitored without creating pathways for adversary lateral movement.

Jump server architecture — requiring that all access to Layer 3 systems passes through a controlled, session-recorded jump server at Layer 2, creating an audit trail for access even when the device itself cannot produce one.

Credential inventory and hardcoded credential remediation — systematically documenting every default and hardcoded credential in the environment, working with vendors on whether firmware updates or configuration changes can address them, and documenting which cannot be changed and why as a risk-accepted item with compensating controls attached.

Break-glass procedures with dual control — defining in advance how emergency access to Layer 3 systems is authorized, documented, and reviewed, with dual-person controls on the most critical access scenarios.

Physical security as a governance layer — at Purdue Level 0 and 1, physical access controls are a legitimate and important part of the credential governance picture. A device that cannot authenticate digitally can still be protected by controlling physical access to it.


The governance principle that ties all three layers together

The three layers require different tools and different approaches. But they require the same governance discipline: every privileged credential in the environment needs to be inventoried, classified by risk tier, assigned an owner, and subject to a defined process for access, rotation where possible, and review.

The credentials that cannot be rotated are not exempt from governance — they are the most important ones to govern, because they represent standing risk that compensating controls must address. A hardcoded PLC credential documented in the inventory, with network segmentation and jump server controls attached to it, is a managed risk. The same credential undocumented and unaddressed is an unmanaged one.

You cannot govern credentials you have not inventoried. In OT environments, the inventory itself is the first governance act — and for many organizations, it is still not done.

The SANS 2025 ICS/OT Security Report found that the biggest opportunities in OT security are no longer purely technical — they are leadership, governance, and clarity-of-role opportunities. That observation maps directly to the credential problem. The technology to govern Layer 1 and Layer 2 credentials exists. The organizational discipline to inventory all three layers, assign ownership, define processes, and hold the lines under operational pressure is where most programs fall short.


What this means for IAM practitioners working in OT environments

If you come from an enterprise IAM background — SailPoint, CyberArk, Okta, Entra ID — the OT credential governance problem will feel familiar in structure and disorienting in execution. The governance principles transfer. The tools often do not. The stakeholders are different. The risk of getting it wrong is different. Patching a misconfigured identity rule in an enterprise directory produces a help desk ticket. Disrupting a credential dependency on a safety interlock can produce a production shutdown.

The discipline that matters most in OT credential governance is the same discipline that matters in enterprise IAM: start with the inventory, establish ownership, and govern what you can reach while documenting and compensating for what you cannot. The layered architecture exists not because it is elegant, but because the environment demands it.

Passwordless authentication is coming to OT environments. It is already achievable at Layer 1 and extending into parts of Layer 2. It will not reach every field device in a 20-year-old power generation facility in the next decade. The organizations that wait for a complete solution before building governance will spend that decade with the bottom two-thirds of their credential surface unmanaged.

Start with the inventory. Build the three layers. Document what you cannot yet govern and why. That is where OT credential governance begins.

Sources & References

Dragos. OT/ICS Cybersecurity Year in Review 2025. Dragos, Inc., February 2026. dragos.com

SANS Institute. State of ICS/OT Security 2025. SANS Institute, November 2025. sans.org

IBM X-Force. X-Force Threat Intelligence Index 2026. IBM Security, 2026.

Fortinet. State of OT and Cybersecurity 2025. Fortinet, 2025. fortinet.com

Waterfall Security. Threat Report 2023. Waterfall Security Solutions, 2023.

ISA/IEC 62443. Industrial Automation and Control System Security. International Society of Automation.

CyberArk. "Redefining PAM to Secure OT and IoT Devices." CyberArk Blog, February 2025. cyberark.com

InsightsIdentity GovernanceOT Credential Architecture

Identity Governance  ·  OT / ICS Security

A Vault Is Not Enough for OT Password Management

Why OT credential management needs human identity, privileged vaulting, and offline-capable edge enforcement.

Industrial organizations are investing in modernization, zero trust, and passwordless identity. But in OT, access control remains one of the hardest problems to solve — because the environment does not behave like enterprise IT, and the tools built for enterprise IT were not designed for it.

The 2025 SANS ICS/OT Security Survey, drawing on responses from 330 industry professionals, documents the scope of the gap: half of reported ICS/OT incidents stemmed from unauthorized external access, yet only 13% of organizations had implemented advanced controls such as session recording or OT-aware authentication. The problem is not simply that organizations are using weak passwords. The problem is that most organizations lack the access governance infrastructure to control who can access critical systems, how that access is approved, what credential is used, whether the session can be monitored, and how evidence is preserved when production environments are offline or legacy-heavy.

OT does not have a password problem alone. It has a credential-governance architecture problem. Replacing passwords is necessary but not sufficient. Governing the full lifecycle of access — approval, release, monitoring, rotation, and audit — requires three control planes working together, not one tool applied to all three.


Why this problem has persisted

The problem has not persisted because OT teams do not care about security. It has persisted because most security tools were built around IT assumptions: always-on connectivity, modern protocols, centralized policy enforcement, fast patch cycles, and cloud-based identity flows. OT environments break all of those assumptions simultaneously.

NIST SP 800-82 Rev. 3 establishes the foundational reason: OT systems interact with the physical environment and are constrained by availability, safety, and reliability requirements that have no equivalent in enterprise IT. A control that works cleanly in a cloud-first environment may create unacceptable friction in a production environment where uptime, safety interlocks, and maintenance windows determine what is feasible.

The April 2026 CISA guidance on Adapting Zero Trust Principles to Operational Technology, co-authored with the Department of Energy, FBI, and Department of State, makes this explicit: applying zero trust to OT requires accounting for technology gaps from legacy infrastructure, operational constraints, and the safety requirements that arise from the critical link between cybersecurity and physical processes. Importantly, the guidance also states that no single tool or silver-bullet technology resolves these operational challenges. Transition architecture matters. Compensating controls matter. Governance matters — especially where modern tooling cannot yet reach.


Passwordless is necessary — and incomplete

Passwordless authentication matters. It can meaningfully improve accountability for shared workstations, HMIs, kiosks, and factory-floor terminals. Products like 1Kosmos 1Key provide FIDO-compliant biometric authentication for shared account login environments specifically designed for OT systems, with a focus on accountability and auditability — addressing the real problem of shared accounts where multiple operators use a single login.

But authenticating the human is not the same as governing the credential used by legacy equipment, engineering software, shared local accounts, or device firmware. Even in modern shared-account workflows that use passwordless authentication at the front end, the backend credential still has to be stored somewhere, retrieved under controlled conditions, authorized against a workflow, rotated on a schedule, and audited for evidence. Passwordless proves who the engineer is. It does not, by itself, govern every credential the machine still requires.

The distinction matters because most OT environments contain all three categories simultaneously: modern systems that can support passwordless authentication, legacy systems that require PAM-managed credentials, and field devices that require compensating controls because they cannot participate in modern identity governance at all. A single-tool strategy addresses only the first category.


Three control planes, not one tool

The mistake most organizations make is treating OT credential management as a single-tool problem. It is not. It is a three-control-plane problem, and each plane answers a different question.

Control Plane Question It Answers What It Requires
Human Identity Who is the engineer, operator, vendor, or maintainer? Passwordless authentication, MFA, biometrics, device trust, role assignment
Credential Governance What credential is used, approved, rotated, and audited? PAM vaulting, manager approval workflow, rotation evidence, least privilege, lifecycle governance
Edge Execution How does access work safely in disconnected, legacy, or latency-sensitive environments? Offline cache, shift-scoped leases, gateway/proxy, local audit logs, break-glass procedures

Identity verifies the human. The vault governs the secret. The edge layer enables execution where the central system cannot be assumed to be available. Collapsing these three into a single tool is what creates the governance gaps that most OT environments are currently operating with.


The vault as system of record, not password safe

A PAM vault is not valuable primarily because it stores passwords securely. It becomes valuable because it creates the governance layer around credential use: who requested access, who approved it, what credential was released, how long it was valid, whether it was rotated after use, and what audit evidence remains for compliance review.

WALLIX describes this model in OT contexts: credentials are stored in a secure vault, automatically injected when users connect to OT systems, centrally rotated on a defined schedule, and never exposed to the operator directly. The operator never handles the credential — they authenticate as themselves, request access through a workflow, and the vault brokers the session. That architecture enforces least privilege, creates an approval record, and makes rotation practical even for shared accounts.

In mature OT credential governance, the vault functions as the system of record for the entire credential lifecycle. Not just where the password is stored — but where every access event, approval decision, rotation confirmation, and session record lives. That record is what regulators, auditors, and incident responders need to see.


The edge layer: why offline-first is not optional

This is where OT credential architecture separates from enterprise IAM most sharply. In enterprise IT, a failed access request blocks a user from an application. In OT, a failed access path may affect maintenance, production recovery, safety response, or operational continuity. That changes the design principle fundamentally.

NIST SP 800-82 Rev. 3 frames OT around systems that monitor and control the physical environment — where availability and safety are the primary design constraints, not security convenience. The CISA OT Zero Trust guidance reinforces this: OT environments require risk-informed exception handling and compensating controls when traditional zero trust mechanisms are impractical or disruptive to OT processes. Organizations must design for the scenario where the central PAM system is unreachable, the WAN connection to the corporate network is down, or the production cell is deliberately isolated for a maintenance window.

OT credential governance must be offline-aware by design. That means the edge layer needs to function when the vault is unreachable — and sync accurately when connectivity is restored. The controls that make this work include:

  • Shift-scoped credential leases with defined expiration — access that expires automatically at the end of a maintenance window
  • Encrypted local cache on the edge node — credentials accessible offline without exposure to the network
  • Device binding — credentials tied to specific authorized endpoints, not transferable
  • Local tamper-evident logging — audit trail preserved locally and synced to the vault on reconnect
  • Vault-wins conflict resolution — when sync occurs, the vault's record of credential state takes precedence
  • Break-glass procedures with post-incident review — documented emergency access paths that create an audit obligation, not an audit gap

Where gateways and proxies fit

A gateway or proxy is a useful enforcement point within the edge execution layer — but it is not the entire architecture. XONA Systems notes that standard IT PAM tools can struggle in disconnected, degraded, intermittent, or low-bandwidth environments, while OT-optimized solutions support credential injection and just-in-time access without requiring VPNs or jump servers in industrial environments. WALLIX describes a similar model: users authenticate with their own identity while the OT session uses managed credentials they never see.

A gateway can broker access, inject credentials, record sessions, and prevent the engineer from handling the password directly. But protocol compatibility, legacy device behavior, production-cell topology, cost, failure recovery, and offline behavior all determine whether the gateway is the primary enforcement point or one option among several. The gateway belongs inside the edge execution layer. It does not replace human identity, credential governance, or audit accountability. It implements part of what the edge layer requires.


In regulated environments, the audit trail is a control requirement

For critical infrastructure operators in the energy sector, this is not a governance preference — it is a compliance mandate. NERC CIP-005-7 requires documented processes for remote access management, mandates that Interactive Remote Access sessions use an Intermediate System so the initiating cyber asset does not directly access the applicable cyber asset, and requires multi-factor authentication for all Interactive Remote Access. It also requires methods to determine and disable active vendor remote access sessions — meaning the organization must be able to see who has an active session and terminate it on demand.

The audit trail is not administrative overhead. In critical infrastructure, it is part of the control. An organization that cannot demonstrate who accessed what, through what path, under what approval, for how long, and with what ability to monitor or terminate that access is not compliant — regardless of how strong the underlying credentials are.

The question is not whether OT should adopt passwordless identity. It should. The better question is whether passwordless alone reaches every layer where credentials still create risk.


The threat reality that makes this urgent

Dragos' 2026 OT/ICS Year in Review tracks 26 threat groups targeting OT environments, 11 of which were active in 2025. Three new groups were identified during the year. The briefing emphasizes that organizations still struggle to implement basic controls — which directly affects how quickly and effectively they can respond when attacks occur.

As adversaries increasingly understand industrial operations and target access paths into OT environments, credential governance cannot remain a back-office IAM concern. Shared credentials, remote access channels, vendor access sessions, and privileged paths to control systems are part of the industrial attack surface. Volt Typhoon, documented in the CISA OT Zero Trust guidance, demonstrated that exfiltrating Active Directory credentials from the IT network is sufficient to move laterally into OT environments when shared domains or credentials bridge the two. The access path is the attack surface.


The future may be passwordless. The transition still needs governance.

The right direction is clear. OT environments should move toward stronger machine identity, certificates, cryptographic authentication, and passwordless patterns wherever supported. The CISA OT Zero Trust guidance explicitly supports this trajectory, recommending that organizations use procurement to facilitate the gradual transition away from legacy infrastructure and toward components that support modern ICAM capabilities.

But critical infrastructure cannot wait for every legacy asset to be replaced before reducing credential risk. A practical OT credential strategy has to be tested against the actual constraints of the environment — connected sites, disconnected sites, mixed PLC generations, manager approval workflows, offline access requirements, audit completeness, and failure recovery behavior.

The architecture that works across all of those constraints is not a single tool. It is three control planes operating together: authenticate the human, govern the credential, enforce access at the edge, and preserve auditability even when the network is offline. In OT, identity strategy cannot stop at the login screen. It has to follow the credential all the way to the machine.

Sources & References

SANS Institute. State of ICS/OT Security 2025. SANS Institute, 2025. sans.org/white-papers/state-of-ics-ot-security-2025

Fortinet. "From Insight to Action: What the 2025 SANS ICS/OT Security Report Means for You." Fortinet Blog, 2025.

NIST. SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security. National Institute of Standards and Technology, 2023. csrc.nist.gov/pubs/sp/800/82/r3/final

CISA, DoW, DOE, FBI, DOS. Adapting Zero Trust Principles to Operational Technology. April 2026. ic3.gov/CSA/2026/260429.pdf

1Kosmos. "1Kosmos 1Key Protects Shared Login Environments and OT Systems." 1kosmos.com

WALLIX. "OT Use Case: Password & Credential Management." wallix.com

Xona Systems. "Privileged Access Management (PAM)." xonasystems.com

NERC. CIP-005-7: Cyber Security — Electronic Security Perimeter(s). NERC, 2021. nerc.com

Dragos. OT/ICS Cybersecurity Year in Review 2025. Dragos, Inc., 2026. dragos.com

InsightsARGM™Practitioner Guide v1.2

Innowaze Ventures · AI Agent Governance

ARGM™ Practitioner Guide

How to score, classify, and govern AI agents using the Agent Risk Governance Matrix™ — from first assessment to operational controls.

Versionv1.2
Last updatedJune 2026
AuthorVictoria Galloway

The Practitioner Guide is the operational companion to Article 3: Introducing the ARGM™. It contains the weighted scoring model, pillar-by-pillar rubric, governance gate logic, evidence standards, operational templates, lifecycle governance, and the interactive weighted scorer.

Quick start

1

Read Article 3 to understand the framework

2

Use the rubric to score your agent across 7 pillars

3

Apply the governance tier and required controls

Full Guide Available

Download the Complete Practitioner Guide

The full guide includes the weighted scoring formula, complete rubric, governance gate logic, evidence standards, RACI template, scoring worksheet, decision matrix, lifecycle governance, failure modes, four example assessments, glossary, and the interactive weighted scorer.

Request Access → Or reach out at victoria@innowaze.org

Scoring overview

The ARGM™ evaluates agents across two separate dimensions. Pillars 1–5 establish inherent risk. Pillars 6–7 establish governance posture. Strong posture never lowers the inherent risk tier.

Inherent Risk · Pillars 1–5

P1 Impact
P2 Privileges & Access
P3 Functional Authority
P4 Execution Frequency
P5 Data Sensitivity

Governance Posture · Pillars 6–7

P6 Accountability (1=strong, 4=absent)
P7 Visibility (1=strong, 4=absent)

Gate rule: Pillars 6–7 scoring 3 or 4 escalates the final tier. Scoring 3 or 4 on execution-capable agents blocks production deployment.

Governance tiers

TierScoreProfileRecertification
Tier 10–24Low risk. Standard controls. Documented owner and purpose.Annual
Tier 225–49Moderate risk. Formal approval, behavioral baseline, security review.Semiannual
Tier 350–74Elevated risk. Formal release approval, continuous monitoring, incident playbook.Quarterly
Tier 475–100Critical risk. Independent assessment, executive approval, tested kill switch.Quarterly + trigger

Ready to assess your agents?

The full interactive weighted scorer, complete rubric with evidence anchors, governance gate logic, and operational templates are available in the complete practitioner guide.

Book a call to get started →
InsightsLeadershipWhen Leadership Works Like Zero Trust

The Layered Leader Series  ·  Part 2

Quiet Leadership: The Decisions No One Sees

A leader recently asked me something that stayed with me long after the conversation ended.

"You're not in people management yet — but since that's what you aspire to, how would you know if you were successful as a manager?"

I didn't have to think long. The first word that came to mind was trust.

That probably says something about where I've spent my career. In cybersecurity, trust is never assumed. It is established deliberately, protected continuously, monitored constantly, and re-earned at every access point. We don't grant access because someone looks familiar. We verify. We validate. We design systems that assume nothing and confirm what matters.

The framework that best captures this is Zero Trust — and the more I sat with that question, the more I realized: the strongest leaders I've observed operate the same way.


Zero Trust Is Not About Suspicion. It's About Rigor.

One of the most common misconceptions about Zero Trust is that it is adversarial — that it treats everyone like a threat. That is not it. Zero Trust is about building systems where trust is earned through evidence, not assumed through proximity. It replaces "you're inside the perimeter, so you must be safe" with "let's continuously verify that you have what you need, and that what you need is still appropriate."

That distinction matters enormously in leadership. A manager who assumes team cohesion because people show up to meetings is operating on implicit trust — the old perimeter model. Things may look fine from the outside. But underneath:

Someone may be burning out quietly. Someone else may have stopped flagging issues because the last time they did, nothing changed. Someone may be doing invisible work that keeps the team moving, even if it never shows up in the status report.

I say this not from theory, but from observation and experience. High-performing teams often depend on work that is not immediately visible: connecting dots across functions, surfacing issues early, clarifying ambiguity, and creating stability before risks escalate. That has made me more precise about what meaningful investment in a team should look like.


Three Principles, Reframed for Leadership

Zero Trust is built on three core ideas. Each one translates.

Principle 01

Verify Explicitly

Do not assume you know how someone is doing. Ask directly. Create the conditions where honest answers are actually safe to give. A check-in that only produces "I'm good" is not verification — it is a formality.

Real verification means your team members trust that telling you the truth will not cost them their credibility, their opportunities, or their sense of belonging.

Principle 02

Right-Size Responsibility

In security, this is least privilege: giving people the access they need — no more, no less. In leadership, it means right-sizing responsibility, opportunity, and support.

Not everyone on a team is in the same season. Some people are ready to stretch, lead, and take on meaningful challenges. Others may need stability, consistency, and a sustainable pace right now. Effective managers do not apply one development template to everyone. They calibrate.

Principle 03

Assume Breach

This is the hardest principle to translate — but it may be the most important. In security, assuming breach means designing systems as if something has already gone wrong, so you detect it faster and contain it better.

In leadership, it means building a team environment where problems surface before they become crises. Where someone can say "I'm struggling with this" before they are overwhelmed. Where psychological safety is not a value on a slide deck — it is a design principle the manager actively maintains.


Success Looks Different Than I Once Thought

Earlier in my career, I measured professional success almost entirely by output — what got delivered, what got closed, what moved. Those things still matter. Delivery is real. Outcomes are real. A team that does not execute is not serving the mission.

But I have come to believe that behind every high-performing team is a manager doing work that does not always show up in a status report: creating the conditions where people can do their best work without losing themselves in the process.

A strong team should deliver results. But it should also leave people better than it found them.


What I'll Carry Forward

I am not a people manager yet. But I think about it the way I think about any system I am responsible for designing — with intention, with rigor, and with deep respect for what happens when the architecture fails the people inside it.

Long after someone leaves your organization, they may not remember every metric or milestone. But they will remember whether they felt seen. Whether they felt safe. Whether being on your team made them believe more deeply in what they were capable of becoming.

That is the measurement that matters to me. And if I ever get the privilege of leading a team, Zero Trust will not just be the framework I build security programs on. It will be how I lead.

InsightsLeadershipLeadership Is Layered

The Layered Leader Series  ·  Part 1

Before the Title: The Layers That Shape a Leader

"People may forget what you said or what you did, but they will never forget how you made them feel." — Maya Angelou

We often think leadership begins with a promotion, a title, or the moment someone gives us authority. I don't believe that's where leadership begins. I believe leadership begins much earlier — in the experiences that shape us, the people who believe in us, and the quiet moments that teach us how to show up for others.

Leadership, I've come to realize, is layered.

Think about a time when someone made you feel seen. Heard. Valued. Those moments often seem small while they're happening, yet they stay with us for years. They shape our confidence, influence our decisions, and often determine how we choose to show up for others.

That's why I believe leadership begins long before a promotion, a title, or an organization decides to call someone a leader. Leadership begins in moments. It begins in people. It begins quietly.


Leadership Begins Like a Seed

Leadership doesn't arrive all at once. It begins quietly. In layers. Like a mustard seed — small enough to overlook, easy enough to underestimate. But once it's planted, something begins to change. Not overnight. Not dramatically. But steadily.

Leadership grows the same way. It isn't built through one defining achievement. It's formed through the accumulation of experiences, choices, relationships, and responsibilities that shape who we become over time.

Every challenge adds a layer. Every difficult conversation adds a layer. Every moment we choose courage instead of comfort adds another layer. Before long, what once felt small becomes foundational.


We Don't Lead as Titles. We Lead as Layered People.

I've never liked introducing myself by my job title. Titles explain what we do. They rarely explain who we are. I prefer to think of people as layered.

Some of my earliest layers were formed long before I understood what leadership even meant. At four years old, surviving cancer taught me resilience. Years later, serving as a caregiver for my grandmother taught me empathy, patience, and vulnerability. It taught me what it means to continue showing up when life is heavy.

Those experiences didn't make me louder. They made me steadier. And that's a lesson I continue to carry into every leadership opportunity.


Quiet Leadership

Today, I work in cybersecurity and program management. Both disciplines have reinforced something I now believe deeply: the best leadership is often invisible.

In cybersecurity, many of the people we protect are people we will never meet. Many of the successes we create are the incidents that never happen. Leadership in cyber is about early decisions — the decisions made before something breaks. The diligence that no one applauds. The responsibility no one notices. When everything works, it often looks like nothing happened at all.

That is quiet leadership. It is choosing care before crisis. Preparation before recognition. Responsibility before visibility.

Program management has taught me a complementary lesson. Leadership isn't about controlling people — it's about creating alignment. Building clarity before execution. Creating structure that allows innovation to thrive. Designing processes that serve people, not the other way around. Building trust through consistency. Taking ownership when challenges arise. Removing obstacles so others can succeed.

Whether we're leading projects, organizations, communities, or families, our role is often the same: create an environment where others can do their best work.


Leadership Is About What You Leave Behind

One of the greatest misconceptions about leadership is that it's about becoming someone important. I've found the opposite to be true. Leadership is far less about who we become than it is about what we cultivate in other people.

If you want to go fast, go alone. If you want to go far, go together.

That's leadership. Because leadership isn't measured by how many people follow us. It's measured by how many people grow because of us. The encouragement we give. The confidence we build. The opportunities we create. The trust we earn. The belief we plant in someone before they fully believe in themselves. Those are the things that continue growing long after we've moved on.


What Layer Are You Building in Someone Else's Life?

As leaders, we're constantly planting something. Sometimes it's courage. Sometimes it's trust. Sometimes it's clarity. Sometimes it's hope. And many times, we'll never know which conversation, decision, or act of kindness becomes the moment someone else looks back on and says: "That changed me."

So before asking what kind of leader you want to become, ask yourself a different question.

What layer are you building in someone else's life?

Every conversation adds a layer.

Every act of encouragement adds a layer.

Every difficult decision made with integrity adds a layer.

Every person who believed in us added a layer to who we became.

Leadership is layered. And leadership is not who you become. It is who rises because you were there.

InsightsProgram & Portfolio LeadershipInfluence Without Authority

Program & Portfolio Leadership

Why Strong Program Managers Learn to Influence Without Authority

One of the most difficult realities of program management is that you may be accountable for an outcome without directly managing everyone responsible for delivering it.

You may own the roadmap, the timeline, the risk, the executive updates, and the overall success of the program. But the engineers, analysts, vendors, business owners, legal partners, compliance teams, finance representatives, and operational leaders involved may report to someone else. You cannot simply instruct everyone to prioritize your work. You have to earn alignment.

That is why one of the most important skills a program manager can develop is the ability to influence without authority. This does not mean manipulating people, playing organizational politics without integrity, or trying to become the most persuasive person in every room. It means understanding how to build trust, communicate value, clarify ownership, navigate competing priorities, and help people see how their work connects to a shared outcome.

Program managers do not succeed because they control everyone involved. They succeed because they create the conditions that allow people to move together.


Accountability without direct control

Traditional management structures often rely on positional authority. A manager assigns work, sets expectations, evaluates performance, and has formal responsibility for the people on the team. Program management frequently works differently.

A program manager may coordinate people across multiple departments, vendors, geographic locations, leadership levels, and technical domains. Each group has its own priorities, deadlines, leadership, incentives, risks, constraints, and definition of success. The program manager is responsible for connecting those different realities into one coordinated delivery model. That requires more than project plans and meeting invitations. It requires influence.


Influence begins with understanding

A common mistake is assuming that people resist a program because they do not understand its importance. Sometimes they understand it perfectly. They may simply be protecting something else.

An engineering team may be concerned about technical debt. A business leader may be focused on operational disruption. Finance may be protecting the budget. Legal may be considering contractual exposure. Compliance may be concerned about auditability. An executive may be weighing the program against several other strategic priorities.

Strong program managers do not immediately interpret every objection as unwillingness, incompetence, or lack of commitment. They learn to ask what this stakeholder is responsible for protecting, what competing priorities are affecting their decision, what risk they see that the program manager may not see, what information they need, and what tradeoff is being asked of them.

Influence starts with understanding the world from the other person's position. That does not mean abandoning the program's needs. It means developing a recommendation that reflects organizational reality rather than only the program's own timeline.


Build relationships before the escalation

The worst time to begin building a stakeholder relationship is when you already need that person to approve, prioritize, fund, or rescue something. Trust built only during an escalation often feels transactional.

Strong program managers develop relationships before the program reaches a crisis. They learn who the key decision-makers are, but they also identify the informal influencers — the people whose opinions shape decisions even when they do not hold the highest title. They ask questions before making requests. They communicate consistently. They follow through on commitments. They give credit. They share context. They do not contact stakeholders only when something is wrong.

Relationships create the social infrastructure through which difficult work becomes possible. When trust already exists, stakeholders are more likely to raise risks early, provide honest feedback, and work collaboratively through challenges.


Translate the program into their language

A program manager may understand why an initiative matters, but that does not mean every stakeholder will interpret its value the same way. Different audiences require different framing.

An executive may need strategic impact, financial exposure, enterprise risk, and tradeoffs. An engineering team may need technical requirements, dependencies, and architecture implications. An operational team may need process changes, downtime expectations, and support models. A compliance partner may need control mappings, evidence requirements, and audit implications.

The message should remain truthful and consistent, but the emphasis must change based on the audience. That is not inauthentic. It is translation. Strong program managers do not simply repeat the same presentation to every group. They connect the program to what each audience is responsible for understanding and protecting.


Stop reporting activity and start enabling decisions

Program managers often become trapped in status reporting. They collect updates, create slides, schedule meetings, and report what happened. Those activities may be necessary, but they are not the highest form of program leadership.

Influence grows when the program manager moves from reporting activity to enabling decisions. Instead of saying "the integration remains delayed," a stronger update might say:

"The integration is two weeks behind because the current design requires additional security testing. We have three options: reduce the initial scope, add temporary resources, or move the launch date. My recommendation is to reduce the initial scope because it protects the critical control objective without increasing cost."

The second version does more than communicate a problem. It gives leaders context, options, tradeoffs, a recommendation, and a decision to make. Program managers increase their influence when stakeholders trust them to bring clarity rather than simply surface complexity.


Create shared ownership

People are more likely to support what they helped shape. That does not mean every decision should be made by committee. It means key stakeholders should have meaningful opportunities to contribute before the direction is finalized.

Strong program managers involve people early enough to influence the approach — not after every major decision has already been made. This creates better plans, but it also creates ownership. There is a significant difference between "the program team decided this is what you need to do" and "we worked through the constraints together, and this is the approach we agreed gives us the strongest path forward." The second creates commitment rather than mere compliance.


Clarify ownership without becoming controlling

Influence without authority does not mean avoiding accountability. Program managers still need to establish who owns each deliverable, what completion means, when it is due, what dependencies exist, who can make which decisions, and when an issue must be escalated.

Ambiguity weakens influence because it creates space for assumptions, missed expectations, and conflicting interpretations. Clarity strengthens influence. The goal is not to control every detail. The goal is to make responsibilities visible enough that people can coordinate effectively. A mature program manager knows the difference between oversight and micromanagement. Oversight creates visibility, removes obstacles, and supports accountability. Micromanagement takes ownership away from the people responsible for doing the work.


Learn how to make a clear ask

Many program-management conversations fail because the request is buried beneath too much background information. A strong ask makes four things clear: what is needed, who needs to provide it, when it is needed, and why it matters.

Instead of "we have been discussing access requirements for several weeks and are becoming concerned about the timeline," say: "We need the final access requirements approved by Thursday to preserve the testing window. Sarah owns the approval. Without it, the launch moves by at least two weeks."

Clarity is a form of respect. It allows people to understand what is being requested and decide how to respond.


Use escalation as governance, not punishment

Some program managers avoid escalation because they fear damaging relationships. Others escalate too quickly because they view escalation as a way to force action. Both approaches can weaken trust.

Escalation should be a governance mechanism, used when a decision exceeds the team's authority, competing priorities require leadership intervention, a significant risk cannot be resolved at the working level, ownership remains unclear, or a deadline or control objective is materially threatened. A responsible escalation includes the issue, the impact, the actions already taken, the unresolved decision, the available options, and the recommended path.

Escalation should not surprise people unnecessarily. Whenever possible, the affected stakeholders should know that an issue is being raised and understand why. The goal is not to embarrass someone. The goal is to obtain the decision or support the program cannot secure at its current level.


Develop credibility through consistency

Influence is rarely created through one impressive meeting. It develops through repeated evidence that the program manager is reliable. Do you follow through? Do you communicate early? Do you distinguish facts from assumptions? Do you acknowledge uncertainty? Do you give credit to the people doing the work? Do you remain calm when the program is under pressure?

Consistency builds credibility. Credibility creates influence. Influence makes coordinated execution possible.


Mission over ego

Influencing without authority requires humility. A program manager cannot be committed only to being right, appearing competent, or receiving recognition. The mission has to remain larger than the individual.

Sometimes another person will have the better idea. Sometimes a stakeholder's objection will reveal a weakness in the plan. Sometimes the program manager will need to change the approach, repair a relationship, or acknowledge that the original recommendation was incomplete. That is not a loss of authority. It is evidence of judgment.

The strongest program managers do not need to be the smartest person in every conversation. They need to make it easier for the collective intelligence of the program to produce a strong outcome.


The real work of program leadership

Program management is often described through schedules, budgets, risks, dependencies, and deliverables. Those disciplines matter. But as programs become larger and more complex, the work becomes increasingly human.

The program manager must help people with different priorities, incentives, communication styles, and responsibilities move toward a shared objective. That requires trust, clarity, translation, judgment, relationship-building, accountability, adaptability, and ethical influence.

You may not have direct authority over every person involved. But you can create direction. You can build alignment. You can clarify decisions. You can strengthen relationships. You can connect people to the mission. And you can develop the credibility that causes people to trust your leadership, even when they do not report to you.

That is the difference between coordinating work and leading a program.

The Intersection of Cybersecurity,
Identity Governance, and What's Coming Next

VG
Victoria Galloway
Founder, Innowaze Ventures LLC
Credentials & Recognition
  • Cybersecurity Program Manager, The Boeing Company
  • IAM Platform Lead — CyberArk, SailPoint, Okta, Entra ID
  • Master of Information & Cybersecurity, UC Berkeley
  • Project Management Professional (PMP)
  • CISSP (In Progress)
  • BEYA Tech Leader Award Recipient
  • Women of Color Rising Star Award
  • Top Secret Clearance
  • $4M+ Annual Cost Savings Delivered

Why Victoria?

Victoria Galloway operates at the intersection of cybersecurity, identity governance, and emerging technology. After leading enterprise identity and security transformation programs in some of the most complex environments in the country, she founded Innowaze Ventures to help organizations establish trust, accountability, and governance in a rapidly changing technology landscape — before a compliance event, breach, or audit forces the issue.

Most organizations are deploying technology faster than they're governing it. AI agents are being provisioned without identity controls. Access is accumulating without accountability. Compliance obligations are growing without dedicated leadership. That gap is exactly where Innowaze works.

At Boeing, Victoria led large-scale IAM programs spanning CyberArk PrivCloud, SailPoint IdentityNow, Okta, and Microsoft Entra ID — delivering over $4M in annual cost savings and significantly reducing audit findings and identity risk across the enterprise.

She is also developing the Agent Risk Governance Matrix™ (ARGM™) — one of the first practical frameworks for governing AI agents as participants in business processes, not just tools. Her four-part AI Agent Governance series and companion practitioner guide are the foundation of that work.

Identity & Access Management

SailPoint, CyberArk, Okta, Ping Identity, Microsoft Entra ID, IGA program management

AI Governance

Agent risk frameworks, NIST AI RMF, non-human identity governance, shadow AI

GRC & Compliance

NIST CSF, CMMC, SOX, HIPAA, audit readiness, risk register management

Program & Portfolio Management

PMO design, executive reporting, roadmap development, stakeholder alignment

The Work That Drives the Work

Innowaze Ventures reflects a larger vision — that technology governance, cybersecurity literacy, and community access to technology should not be reserved for enterprises with unlimited resources.

Nonprofit Founder

Lifted Hands International

An Atlanta-based nonprofit focused on workforce development and STEAM/cybersecurity education for underserved communities. The mission that anchors everything else.

Thought Leadership

AI Agent Governance Series

A four-part series introducing the ARGM™ — a practical framework for governing AI agents as participants in business processes.

Read the ARGM™ Framework →
Speaker & Advocate

Community Technology Advocate

Available for conferences, panels, and community events on AI governance, identity security, and building careers in cybersecurity — particularly focused on visibility for Black women in technical leadership.

View speaking topics →

Where Expertise Meets Emerging Risk

Drawing on enterprise experience in IAM, AI governance, and security transformation to give audiences practical, credible perspectives they can act on.

AI Governance

The Missing Layer in AI Governance: Identity, Trust, and Accountability

As AI agents become participants in business processes, organizations need governance frameworks that address non-human identity, continuous verification, and accountability. A practical session for technology and security leaders deploying AI.

Identity Governance

Non-Human Identities: The Access Risk Enterprise Organizations Are Ignoring

Service accounts, bots, and AI agents now outnumber human identities in many enterprise environments. This session examines how IGA programs must evolve to govern the full identity lifecycle — human and non-human.

Leadership & Transformation

Building Security Programs That Survive Leadership Changes

Most security programs are person-dependent. This session covers how to institutionalize governance, documentation, and program structure so security outlasts any individual.

Women in Cybersecurity

Navigating Enterprise Cybersecurity as a Black Woman Leader

A candid conversation about building technical credibility, navigating enterprise environments, and creating pathways for the next generation of diverse cybersecurity leaders.

Book Victoria to Speak

Available for keynotes, panel discussions, podcast interviews, and executive briefings. Reach out to discuss topics, format, and availability.

Request Speaking Inquiry →

“We don't just assess your risks and hand you a report. We help you fix them — and create an organization stronger, smarter, and ready for whatever comes next.”

— Victoria Galloway, Founder — Innowaze Ventures LLC