For years, GRC has operated one step removed from the systems it governs. A control requires access to be reviewed, so a report is exported to a spreadsheet, sent to an owner, approved, and eventually attached to a control record. An auditor asks whether MFA is enabled, so someone provides a screenshot. Vendor questionnaires, annual attestations, ticket histories, policy documents, sampled logs, and manually exported reports complete much of the evidence trail.
These mechanisms have served a purpose, and many will continue to. The problem is that they often tell us what a system looked like at one point in time, after someone manually reconstructed the evidence.
The systems themselves are moving much faster.
Cloud infrastructure already put pressure on this model. AI will push it further because software is beginning to do more than execute predetermined instructions. It can retrieve information, use credentials, call tools, interact with other systems, delegate work, and increasingly take actions on behalf of people and organizations.
Governance cannot continue operating primarily at quarterly or annual speed while the systems being governed operate continuously. Controls, evidence, and assurance will have to move closer to the technology itself.
There are signs that this shift is already showing up in the labor market. An October 2026 analysis by AKA Security compared 137 U.S. GRC job postings from spring 2024 with 309 from fall 2026. The share carrying an engineer or developer title increased from 4 percent to 24 percent. During the same period, postings asking for automation rose from 18 percent to 47 percent, while those asking for a programming language increased from 3 percent to 15 percent (AKA Security, 2026).
The sample leans toward technology-oriented employers, so those numbers should not be interpreted as evidence that every GRC role is turning into an engineering position. The more interesting signal is that engineering practices are entering GRC much faster than they used to.
The GRC engineer may be arriving as a set of capabilities before the title itself becomes standard.
GRC is becoming a systems problem
This does not mean every GRC professional needs to become a software engineer. It does mean that understanding how systems behave, how data moves through them, and how controls are actually enforced is becoming much more valuable.
Consider access control. A traditional governance question might ask whether access to a sensitive application is reviewed periodically. That still matters, but introduce an autonomous agent and the questions expand quickly.
Which identity does the agent use, and who granted it authority? Is it acting for an employee, a department, or another agent? Which tools can it call, what information can those tools retrieve, and can it delegate work to another system? If it does delegate, what authority travels with that task, how long should it persist, and what happens if the agent begins behaving in a way nobody expected?
A policy document or annual access review cannot answer all of those questions. They increasingly become questions about architecture, identity, authorization, data flows, telemetry, and runtime behavior.
That is where governance begins moving closer to engineering.
Evidence should increasingly come from the system
One of the clearest opportunities is changing how we think about evidence.
Take MFA. A common control test may involve asking an application owner to confirm that MFA is enabled, provide a screenshot, attach an exported configuration report, or complete an attestation stating that the requirement has been met. The same pattern appears elsewhere through spreadsheets of privileged accounts, screenshots of security settings, ticket histories, manually collected logs, questionnaires, and annual confirmations that configurations remain in place.
When the authoritative systems can expose their state directly, much of this starts to look unnecessarily indirect.
Instead of asking whether MFA is configured correctly, an API can query the identity platform. Instead of requesting a spreadsheet of privileged users, current assignments can be retrieved from the source system. Instead of waiting for an annual attestation that encryption is enabled, configuration data can be evaluated against an expected state and monitored for change.
The result can be timestamped, exceptions recorded, deviations routed for investigation, and meaningful changes continuously observed. Evidence becomes something the system produces rather than something a person repeatedly reconstructs.
Current hiring already reflects this direction. Plaid's Security Engineer, GRC role describes work involving continuous control monitoring, automated evidence collection, API integrations, structured control data, policy-as-code, and AI-assisted workflows. General Motors has similarly sought GRC engineering talent to work on automated evidence collection, data pipelines, policy-as-code, and continuous monitoring (Plaid, 2026; General Motors, 2026).
That is more than a faster audit process. It allows GRC professionals to spend less time moving evidence between systems and more time asking questions that actually matter: Is the control working now? When did its state change? Was the deviation authorized? How quickly did we detect it? What risk did the failure create?
AI changes the control problem. More capable AI will change its scale.
AI agents make this transition more urgent because their behavior is shaped by a combination of models, prompts, memory, retrieved information, tools, permissions, and the surrounding environment. Individually reasonable permissions can still combine into an unreasonable outcome.
Imagine a finance agent that can read invoices, create payment requests, and send notifications. Each permission may make sense independently. Now imagine that the agent encounters malicious instructions inside an external document, retrieves sensitive financial information, creates an unusual payment request, and attempts to send information outside the organization.
The permissions may not have changed. The sequence of behavior did.
Governance therefore has to become better at understanding execution, not simply configuration. Which identity was used? Under whose authority was the action taken? What information influenced it? Does the next step still align with the original task, or has the system crossed a boundary that should require additional approval?
These are governance questions, but answering them requires technical visibility.
This also points toward a future in which some policies become executable. A requirement stating that sensitive financial information cannot be transmitted externally without approval does not have to remain only a sentence in a policy document. A control layer could evaluate identity, authority, data classification, destination, and task context before an action occurs, allowing routine activity to proceed while escalating higher-risk actions or blocking those that violate policy.
In that model, enforcement and evidence begin to converge. The decision itself can record what was attempted, which authority was used, which policy applied, and why the action was allowed, denied, or escalated.
Reflection AI is already hiring GRC engineering talent to work on automated controls, technical integrations, continuous evidence collection, data lineage, and translating regulatory requirements into technical specifications. These are early examples, but they illustrate how governance is beginning to move closer to execution (Reflection AI, 2026).
What comes next
I think two developments will accelerate this transition.
The first is that AI agents will move from advising humans to exercising bounded operational authority. The near-term future is unlikely to involve organizations handing unrestricted control of financial systems, hospitals, power infrastructure, or enterprise networks to autonomous software. A more plausible path is gradual delegation, where agents receive authority to perform specific actions within defined limits and under increasingly sophisticated technical guardrails.
We can already see the beginning of that progression. A 2026 Bank of England survey of financial-services firms found that 80 percent of respondents reported agents being used for decision support, while 46 percent reported constrained execution and 22 percent reported conditional autonomy. Only 2 percent reported broad autonomy. The important signal is not that autonomous finance has arrived, but that agents are beginning to move from recommendation into execution within one of the world's most regulated industries (Bank of England and FCA, 2026).
The same direction is appearing elsewhere. Gartner predicts that by 2030, half of organizations will use AI agents with minimal human involvement in IT operations, while the U.S. Department of Energy is developing environments to evaluate large language models and agentic AI in power-system and operational-technology settings (Gartner, 2026; U.S. Department of Energy, 2026).
As that authority expands, access governance will have to expand with it. Organizations will need to know not only what an agent can do, but who delegated that authority, how far it can travel, when it expires, what information can influence the agent's behavior, and whether its current actions still match the purpose for which the authority was granted.
The second development is that assurance will increasingly shift from point-in-time evidence toward runtime proof.
For important controls, mature organizations will increasingly want to know not only whether a control existed during an audit period, but whether it was operating when a consequential action occurred. Was the correct identity acting, was its authority still valid, was the data permitted to move to that destination, and did the action remain within the intended scope?
Point-in-time testing will not disappear. Some risks cannot be evaluated continuously, and human judgment will remain essential. Where authoritative system data exists, however, continuous assurance should increasingly become the preferred model.
GRC platforms may evolve with it. Many function primarily as systems of record today, storing controls, risks, findings, evidence, and workflows. Over time, I expect the stronger platforms to behave more like systems of assurance, continuously consuming control state and risk signals from identity systems, infrastructure, applications, security tools, and eventually autonomous agents.
The more authority we give software, the less governance can remain a process that happens after the fact.
The GRC skill set is expanding
Traditional GRC capabilities are not going away. Risk judgment, communication, business understanding, policy, controls expertise, stakeholder management, and the ability to explain complex issues clearly will remain essential. Technical fluency is increasingly being added around them.
Understanding APIs makes it easier to see how evidence can be collected directly, while understanding identity and authorization clarifies how access is granted and delegated. Working with structured data, queries, logs, and telemetry makes it possible to interrogate systems instead of depending entirely on reports prepared by someone else, and basic programming or automation can turn repetitive assurance work into repeatable processes.
As autonomous systems spread, familiarity with agents, tools, delegated authority, and runtime behavior will become more valuable as well.
The labor-market data supports this interpretation. Automation requirements are appearing in GRC postings much faster than programming-language requirements, suggesting that the profession is not simply becoming software engineering. Engineering capabilities are being layered onto traditional risk and governance work (AKA Security, 2026).
The strongest GRC professionals will not necessarily be those who write the most code. They will be those who understand systems well enough to ask better questions, automate the right work, design stronger controls, and work effectively with the teams building the technology.
Governance should make it easier to say yes
There is a risk that AI governance becomes another approval layer. A new technology appears, a committee forms, questionnaires multiply, policies are drafted, and eventually someone decides whether the organization is comfortable proceeding. That approach will struggle if AI becomes embedded across thousands of ordinary business processes.
A more useful question is:
What would have to be true for us to use this safely?
If an autonomous system has a clear identity, appropriately scoped authority, observable actions, controlled access to information, defined escalation paths, and a reliable way to revoke its permissions, an organization can give it meaningful autonomy with greater confidence.
Good governance should make powerful technology easier to trust and easier to adopt responsibly.
Some organizations will call the people building these capabilities GRC engineers. Others may use titles such as security engineer, technical controls engineer, AI assurance engineer, security automation engineer, or continuous controls engineer. The title matters less than the function.
Organizations still need people who understand what the business is trying to protect and how risk should be managed. Increasingly, they will also need people who can connect those requirements to architecture, identity, data, automation, telemetry, and technical enforcement.
The title may still be emerging, but the function is becoming increasingly necessary. As software gains more authority, governance will have to move closer to execution, and the people responsible for risk will need to understand far more about the systems creating it.
Sources
- AKA Security. Are Security Specialties Turning Into Engineering Jobs? October 2026. Analysis of U.S. cybersecurity job postings comparing spring 2024 and fall 2026, including GRC engineering titles, automation requirements, and programming-language requirements. https://akasecurity.io/research/security-specialties-engineering-jobs/
- Plaid. Security Engineer, GRC. 2026. Current job posting describing continuous control monitoring, automated evidence collection, API integrations, policy-as-code, and AI-assisted GRC workflows. https://plaid.com/careers/openings/security/security-engineer-grc/
- General Motors. Senior Cybersecurity Engineer, GRC Engineering & Technical Controls. 2026. Job posting describing automated evidence collection, data pipelines, continuous control monitoring, policy-as-code, and AI-enabled GRC workflows. https://search-careers.gm.com/en/jobs/jr-202621624/senior-cybersecurity-engineer-grc-engineering-technical-controls
- Reflection AI. GRC Engineer. 2026. Job posting describing automated controls, continuous evidence collection, technical integrations, data lineage, and translation of compliance requirements into technical specifications. https://jobs.ashbyhq.com/reflectionai/ba8037e5-a9d3-4cfe-b8ae-6bb6d817af92
- Bank of England and Financial Conduct Authority. Artificial Intelligence in UK Financial Services 2026. Survey examining AI-agent adoption and levels of autonomy across financial-services firms. https://www.bankofengland.co.uk/report/2026/artificial-intelligence-in-uk-financial-services-2026
- Gartner. Gartner Identifies the Top AI Trends in Infrastructure and IT Operations for 2027. October 2026. Forecast examining growing use of AI agents in IT operations. https://www.gartner.com/en/newsroom/press-releases/2026-10-26-gartner-identifies-the-top-ai-trends-in-infrastructure-and-it-operations-for-2027
- U.S. Department of Energy, Office of Cybersecurity, Energy Security, and Emergency Response. CESER Releases New Testbed to Advance LLM and Agentic AI Evaluation for Critical Infrastructure. July 2026. https://www.energy.gov/ceser
- U.S. Department of Energy. Artificial Intelligence for Operationally Resilient Technologies and Systems (AI-FORTS). 2026. Program addressing secure AI use in energy infrastructure, including systems used to operate, monitor, control, and defend energy assets. https://www.energy.gov/ceser/artificial-intelligence-operationally-resilient-technologies-and-systems