Cover — Continuous GRC for Agentic AI
Autonomous agents do not wait for the next audit cycle before making decisions. They interpret goals, select tools, delegate work, change operational state, and react to new information continuously. Governance, risk, and compliance cannot remain a collection of documents reviewed after those actions have already occurred. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Abstract

Autonomous AI systems operate at a speed, scale, and level of contextual variability that periodic Governance, Risk, and Compliance processes were not designed to address. Models, tools, data, policies, identities, delegations, infrastructure conditions, and risk signals may change between scheduled assessments. By the time a retrospective audit identifies a control failure, an autonomous action may already have produced consequences across multiple systems.

This article presents Continuous Governance, Risk, and Compliance — Continuous GRC as a cross-cutting operational governance capability for agentic AI. Continuous GRC connects approved organizational objectives to machine-enforceable policy, runtime authorization, dynamic risk evaluation, continuous control monitoring, governed exceptions, evidence collection, drift detection, and proportionate response. Governance therefore becomes part of the execution environment rather than a separate documentary process.

The proposed model does not remove accountable human judgment. Instead, it distinguishes decisions that can be automated from those requiring human approval, escalation, review, or intervention. Control failures, missing evidence, policy drift, elevated risk, expired authority, and abnormal behavior can trigger responses such as narrowed permissions, step-up verification, suspension, revocation, containment, or safe degradation.

Within SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture, Continuous GRC links Zero Trust, bounded authority, authenticated delegation, runtime policy enforcement, and Evidence-as-Code into a continuously evaluated governance loop. The model is a conceptual architectural proposal and does not independently establish legal compliance, certification, or empirical proof of control effectiveness.

1. Introduction — Periodic GRC Cannot Govern Continuous Autonomy

Traditional governance, risk, and compliance programs were designed around relatively stable systems, identifiable release boundaries, and human-paced decisions. Policies were approved, controls were documented, systems were assessed, exceptions were recorded, and evidence was assembled for periodic review. Even when monitoring became more frequent, the governing assumptions often remained static between assessments.

Agentic AI changes that operating model.

An autonomous agent can choose among tools, construct new plans, call other agents, reinterpret intermediate results, and operate across cloud, edge, and organizational boundaries. Its effective risk posture may change when a model version changes, a tool is replaced, a delegation expires, a data source becomes unreliable, connectivity is lost, or the operational context no longer matches the conditions under which authority was granted.

In such a system, a control that was valid at deployment may be inadequate seconds later. A policy that exists only in a document cannot constrain a machine-speed action. An audit log that merely records what happened cannot establish whether the action was authorized, which control was evaluated, which evidence supported the decision, or whether the relevant obligation was still satisfied.

Continuous GRC addresses this gap by making governance objectives, risk conditions, controls, exceptions, and evidence part of the operational system. It does not eliminate governance boards, legal interpretation, independent assurance, or human accountability. It connects those functions to runtime decisions through machine-readable policy, event-driven reassessment, explicit risk tolerances, and verifiable evidence.

The central proposition is:

Governance cannot remain a periodic review process when autonomous agents make decisions, delegate authority, invoke tools, and change operational state continuously. GRC must become an executable, evidence-producing runtime capability.

The word continuous must be used carefully. It does not mean that every control is evaluated every millisecond or that all assurance can be automated. It means that the frequency and trigger of evaluation are matched to risk, that material changes can cause immediate reassessment, and that the system can determine whether the conditions for autonomous action remain valid.

This article extends the previous SGAEIA Research Series articles. Bounded and revocable authority defined what an agent may do. Authenticated delegation explained how that authority can cross agent boundaries without becoming transitive trust. Continuous GRC explains how the governing conditions around that authority are maintained, evaluated, evidenced, and changed throughout operation.

2. From Document-Based Compliance to Runtime Governance

Documents remain necessary. Laws, standards, policies, risk assessments, architecture decisions, and contractual obligations require human-readable expression and accountable approval. The problem arises when the document is treated as the control itself.

A statement such as “high-impact containment requires independent approval” has limited operational value unless its meaning can be translated into enforceable conditions that remain traceable to the approved source.

That translation must preserve several properties: the governing intent must remain attributable to an accountable owner; its scope and applicability must be clear; changes must be reviewable; and operational enforcement must not silently redefine the normative requirement.

This creates two synchronized views of governance:

  1. Normative representation — the human-approved obligation, policy, standard, risk decision, or control objective.
  2. Operational representation — the machine-usable expression needed to evaluate whether an action remains compatible with that approved intent.

The operational representation must remain subordinate to the normative one. Translation should be reviewed, testable, versioned, and traceable. When a requirement cannot be reduced to reliable deterministic logic, the system should recognize that boundary rather than create false confidence and should route the decision to accountable human or specialized review.

Open Policy Agent illustrates one implementation family in which policy evaluation is externalized from application code and can be independently managed [1]. The broader architectural principle is implementation-neutral: governance logic should remain explicit, reviewable, testable, and replaceable without embedding irreversible policy assumptions into autonomous agents.

Figure 1 — Periodic GRC vs. Continuous Agentic GRC
Figure 1 — Periodic GRC vs. Continuous Agentic GRC. Periodic assessment produces delayed snapshots; continuous GRC connects approved policy, runtime context, control evaluation, evidence, and governed response. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

3. Why Agentic AI Changes the GRC Operating Model

Agentic systems differ from conventional applications in ways that directly affect GRC.

3.1 Decisions are generated, not fully enumerated

Traditional applications usually expose predefined workflows. Agents may synthesize a plan that was not explicitly encoded by a developer. The action still must remain inside approved authority and risk constraints, even when the path to that action is novel.

3.2 Control flow crosses autonomous components

A coordinator may delegate to a research agent, which invokes a retrieval service, which calls a data transformation tool, which returns evidence used by another agent. Risk and accountability follow this graph, not a single application boundary.

3.3 Context changes the meaning of the same action

Reading a configuration file may be low risk in a test environment and highly sensitive in production. Isolating a host may be appropriate during confirmed compromise but disruptive when evidence is weak. Continuous GRC must evaluate action, resource, environment, purpose, authority, evidence, and current conditions together.

3.4 Models and tools can drift independently

An unchanged agent definition may behave differently after a model update. A tool may retain the same interface while changing its implementation, permissions, or data handling. A policy decision based only on the agent's declared version may therefore miss material dependency changes.

3.5 Machine-speed action compresses response time

If monitoring detects a violation only after a batch export or destructive infrastructure action completes, governance has become forensic rather than preventive. High-impact operations require controls at or before the execution boundary.

3.6 Evidence volume grows with autonomy

Autonomous systems can produce more decisions than humans can manually review. Evidence must be structured so that machines can filter, correlate, validate, and summarize it without replacing independent human judgment.

These properties do not make existing frameworks obsolete. The NIST AI Risk Management Framework organizes risk management around Govern, Map, Measure, and Manage, and explicitly includes ongoing monitoring and periodic review [2][3]. Its Generative AI Profile extends the framework with risks and actions specific to generative systems [15]. ISO/IEC 42001 requires an AI management system to be established, maintained, and continually improved [4]. The challenge is to operationalize these objectives for distributed autonomous behavior without claiming that a technical platform alone creates compliance.

4. Continuous Monitoring Is Not Continuous GRC

Continuous monitoring observes. Continuous GRC decides and governs.

Telemetry may show that an agent invoked a tool, latency increased, a model output changed, or a control test failed. These observations become governance only when they are interpreted against approved obligations, risk tolerances, authority, and response rules.

A useful distinction is:

  • Monitoring collects signals about systems, behavior, threats, controls, and outcomes.
  • Assessment evaluates those signals against defined criteria.
  • Risk analysis estimates the significance of deviations in context.
  • Governance decision determines whether operation may continue and under which conditions.
  • Response enforces that decision and records its effects.
  • Assurance establishes whether the process and evidence are sufficiently trustworthy.

NIST SP 800-137 defines continuous monitoring as providing visibility into assets, threats, vulnerabilities, and control effectiveness so organizations can respond to risk in a timely manner [5]. That foundation is essential, but agentic systems add decisions about delegated authority, model and tool behavior, purpose limitation, emergent workflows, and autonomous response.

Continuous GRC can therefore be expressed as a recurring, event-driven function:

[ G_t = f(P_t, A_t, C_t, R_t, E_t, O_t) ]

where:

  • (P_t) is the applicable policy and obligation set;
  • (A_t) is current authority and delegation state;
  • (C_t) is runtime context;
  • (R_t) is current risk state;
  • (E_t) is available evidence and its quality; and
  • (O_t) is the proposed or continuing operation.

The result (G_t) is not only allow or deny. It may require narrower scope, additional evidence, independent approval, compensating measures, suspension, revocation, or accountable human judgment.

5. Governance Objectives Must Become Executable Policies

Executable governance begins with a controlled transformation from approved obligations into testable operational propositions.

Consider an organizational requirement:

Autonomous agents must not export sensitive incident data outside the approved trust domain.

The governance challenge is not merely to encode a rule. It is to preserve the meaning of the requirement across changing agents, tools, environments, and operational contexts.

A sound executable-policy approach should preserve the following properties:

  • Traceability — operational decisions remain connected to the approved source obligation.
  • Accountability — ownership, approval, and change responsibility remain explicit.
  • Applicability — it is clear which systems, actions, and contexts are governed.
  • Testability — the intended control behavior can be independently assessed.
  • Version integrity — changes are controlled and differences are detectable.
  • Separation of duties — the governed component cannot silently redefine the rules that constrain it.
  • Fail-safe interpretation — ambiguity or missing evidence does not automatically expand authority.

Policy-as-code is therefore only one layer. A syntactically valid rule can still implement the wrong interpretation. Governance requires review, controlled change, independent testing, and evidence that the operational expression remains faithful to the approved intent.

An autonomous agent may propose policy changes, but proposal generation and policy authority are different functions. High-impact governance changes should remain subject to accountable approval and proportionate separation of duties.

6. Continuous Risk Evaluation at Decision Time

Risk is not a static label attached to an agent. It emerges from the relationship among purpose, action, resource, authority, evidence, environment, and potential impact.

For a proposed action (x) at time (t), a simplified risk evaluation might be represented as:

[ R(x,t) = F(I_x, L_x, U_x, C_t, D_t, Q(E_t)) ]

where:

  • (I_x) represents potential impact;
  • (L_x) represents estimated likelihood;
  • (U_x) represents uncertainty;
  • (C_t) represents operational context;
  • (D_t) represents dependency and delegation state; and
  • (Q(E_t)) represents evidence quality and freshness.

The equation is not a universal quantitative model. It highlights that uncertainty and evidence quality must influence autonomous permission. Weak or stale evidence should not be treated as equivalent to verified current evidence.

Reassessment may be triggered whenever a material change affects the assumptions under which an action was previously considered acceptable. Such changes may involve authority, dependencies, operational context, evidence quality, policy, model or tool behavior, or the emergence of a security or safety condition.

The architectural requirement is that high-impact decisions are not justified solely by an agent's own assertion that risk is acceptable. Governance must rely on trustworthy decision context and independent control appropriate to the consequence of the action.

Figure 2 — Runtime Governance Loop
Figure 2 — Runtime Governance Loop. Continuous GRC links Govern, Map, Measure, and Manage as recurring governance functions that reassess whether autonomous operation remains compatible with approved authority, risk, and evidence conditions. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

7. Controls Must Follow Authority and Delegation

The previous article established that delegated authority must narrow at every hop. Continuous GRC adds another requirement: applicable obligations must remain associated with the delegated activity.

Delegation must not become a mechanism for escaping governance. A child agent operating under a narrower grant remains subject to the relevant requirements inherited from the authority context, the protected resource, the operational environment, and the current risk state.

This creates an important asymmetry:

  • delegated authority may become narrower;
  • applicable governance obligations may remain the same or become more restrictive.

As authority changes, governance must remain capable of reassessing whether the conditions that justified earlier decisions are still valid. Material changes in policy, context, evidence, or dependencies may therefore affect existing delegated activity even when the requested action itself has not changed.

The key property is governance continuity across delegation boundaries: delegated activity must remain subject to every obligation that continues to apply to its purpose, context, and effects.

8. Evidence-as-Code as the Compliance Substrate

Continuous GRC depends on evidence that is structured, attributable, time-bound, and independently verifiable.

A conventional log entry such as “agent executed action” is insufficient for high-assurance governance because it records an event without necessarily establishing the authority, policy context, assessment basis, or resulting state that made the event acceptable.

Evidence-as-Code treats governance evidence as a first-class operational artifact whose quality can be evaluated. Useful evidence should preserve properties such as:

  • Attribution — a verifier can determine which accountable principal or authenticated workload produced or authorized the relevant action.
  • Traceability — the evidence can be related to the policy, control objective, authority context, and operational event it supports.
  • Integrity — unauthorized alteration is detectable.
  • Freshness — the verifier can reason about whether evidence was current enough for the decision.
  • Completeness for purpose — the evidence is sufficient for the control claim being made.
  • Reproducibility — an independent reviewer can understand and, where appropriate, re-evaluate the basis of the decision.
  • Portability — evidence can be reviewed outside the component that originally produced it.

These properties matter because continuous governance is only as trustworthy as the evidence on which it relies. More telemetry does not automatically create better assurance.

The W3C PROV ontology provides a general model for representing entities, activities, agents, and provenance relationships [6]. OSCAL supplies machine-readable models for control catalogs, implementation descriptions, assessment plans, assessment results, findings, risks, and remediation information [7][8]. SCITT defines an architecture for authentic, transparent signed statements supported by verifiable data structures [9]. These standards address different layers; none alone constitutes a complete agentic GRC platform.

Figure 3 — Properties of Verifiable Governance Evidence
Figure 3 — Properties of Verifiable Governance Evidence. Governance evidence should remain attributable, traceable, complete for purpose, time-bounded, integrity-protected, and interoperable enough to support independent assessment. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

9. Continuous Control Assessment and Assurance

Continuous control assessment asks whether a control remains implemented and effective under current conditions. It does not assume that deployment success proves continuing effectiveness.

Controls differ in how they can be assessed. NIST SP 800-53, for example, organizes security and privacy controls across families that include assessment, authorization, monitoring, audit, risk assessment, incident response, and supply-chain risk management [14]. Agentic systems must connect such control objectives to their own runtime identities, authority, models, tools, and evidence. Assessment approaches include:

  • Deterministic technical controls can often be tested automatically, such as signature verification, grant expiry, encryption configuration, destination allowlists, or separation of keys.
  • Behavioral controls require statistical or scenario-based evaluation, such as anomalous tool selection, unsafe planning patterns, or model response drift.
  • Process controls may combine workflow evidence and human attestation, such as independent approval or incident review.
  • Governance controls often require accountable judgment, such as risk acceptance, proportionality, or whether an intended use remains appropriate.

Assessment frequency should be risk-based. High-impact and volatile controls may require action-time or event-driven evaluation. Stable configuration controls may be evaluated when their state changes. Organizational controls may be reviewed periodically and when triggering events occur.

OSCAL explicitly supports both snapshot and continuous assessment information, including observations, findings, risks, and links to assessment plans [7]. Its value for agentic systems is interoperability: evidence and assessment results can move between tools without requiring every consumer to understand proprietary formats.

Continuous assurance adds questions about the evidence system itself:

  • Was the evidence producer authenticated and authorized?
  • Is the evidence complete for the action class?
  • Has it been altered?
  • Are clocks and sequence information trustworthy?
  • Were required controls actually evaluated?
  • Can an independent verifier reproduce the decision?
  • Are monitoring blind spots known and bounded?

An automated green status is not assurance if the telemetry source is compromised, the test is obsolete, or the policy-to-control mapping is wrong.

10. Policy Drift, Model Drift, Tool Drift, and Context Drift

Agentic risk changes through several distinct forms of drift.

Policy drift

The deployed executable policy differs from the approved version, or different enforcement locations apply incompatible interpretations.

Model drift

The model's behavior, performance, or risk characteristics change because of model replacement, fine-tuning, routing, updated safeguards, or changing inputs.

Tool drift

A tool's implementation, permissions, interface semantics, dependencies, or destination changes while the agent continues to treat it as equivalent.

Data drift

Input distributions, schemas, quality, provenance, or sensitivity change.

Context drift

The operational environment no longer matches the assumptions under which authority or risk acceptance was granted.

Obligation drift

Applicable legal, contractual, organizational, or sector requirements change, or their interpretation is revised.

NIST's AI RMF Playbook notes that systems may encounter new issues as production environments evolve and describes monitoring as a way to identify drift and accelerate intervention [10]. Continuous GRC should treat drift as a governance event, not merely a performance metric.

A detected drift event should therefore prompt proportionate reassessment of the governance assumptions that may have been affected. The response depends on uncertainty, impact, reversibility, and the trustworthiness of available evidence.

Figure 4 — Types of Drift and Governed Reassessment
Figure 4 — Types of Drift and Governed Reassessment. Material policy, model, tool, data, context, or obligation change should trigger governed reassessment before prior assumptions are allowed to continue unchanged. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

11. Runtime Exceptions and Compensating Controls

Real systems require exceptions. The danger is not the existence of exceptions, but exceptions that become invisible, indefinite, transferable, or broader than the risk decision that authorized them.

A governed exception should preserve several properties:

  • it is explicitly attributable to an accountable decision;
  • it is bounded in scope to the condition that justified it;
  • it is time-bounded and does not become permanent by inertia;
  • it remains reviewable and revocable;
  • it does not silently transfer across unrelated agents, resources, incidents, or purposes;
  • it identifies the relevant residual risk and any compensating expectations; and
  • its continued validity depends on the assumptions under which it was approved.

Exceptions must not become ambient bypass authority. They should remain narrower than the normal governance boundary they temporarily modify.

Compensating controls should also be treated as actual controls rather than labels. Their effectiveness must be independently assessable, and the loss of both a primary and a compensating safeguard should not be interpreted as continued authorization by default.

12. Human Oversight Without Becoming a Bottleneck

Human oversight is essential, but “human in the loop” is not a complete control specification. A person who lacks time, context, authority, independence, or usable evidence may provide only ceremonial approval.

Effective human decision points should define:

  • why human judgment is required;
  • who is accountable and qualified;
  • which conflicts of interest are prohibited;
  • what evidence and alternatives are presented;
  • how uncertainty and potential impact are communicated;
  • how much time is available;
  • what happens if no decision is made; and
  • how the decision is recorded and reviewed.

Automation should prepare a concise, evidence-linked decision package rather than overwhelm reviewers with raw logs. Low-risk, well-bounded decisions may proceed automatically. Higher-risk or ambiguous decisions should escalate based on explicit governance criteria.

Oversight also includes the ability to stop, restrict, or revoke. A dashboard that allows observation but cannot affect authority is monitoring, not operational governance.

13. Continuous GRC Under Intermittent Edge Connectivity

Distributed edge environments cannot depend on permanent connectivity to a central governance function. At the same time, loss of connectivity must not become a compliance or authority bypass.

The central principle is bounded degradation: when governance freshness decreases, autonomous authority should not expand. The system should remain capable of distinguishing what may continue safely from what requires current governance context or accountable intervention.

Offline or intermittently connected operation should therefore preserve properties such as:

  • previously approved governance remains identifiable and bounded;
  • authority available during degraded connectivity is no broader than justified by the reduced assurance state;
  • evidence generated during the disconnected period remains attributable and reviewable;
  • high-impact actions remain subject to stronger constraints when current governance context cannot be established; and
  • reconnection restores authoritative context and allows the consequences of the disconnected period to be reassessed.

The architectural requirement is that loss of connectivity increases uncertainty without silently increasing privilege, and that restored connectivity permits governance assumptions and resulting actions to be reassessed against authoritative context.

14. Regulatory Traceability Without Hard-Coding One Regulation

Continuous GRC must support regulatory obligations without binding the architecture to a single jurisdiction.

The European Union AI Act illustrates lifecycle-oriented requirements for certain regulated systems, including risk management, logging, technical documentation, quality management, and post-market monitoring [11]. ISO/IEC 42001 defines requirements for an organizational AI management system, while ISO/IEC 23894 provides AI risk-management guidance and ISO/IEC 42005 addresses AI system impact assessment [4][12][13]. These sources differ in scope, legal effect, audience, and abstraction.

An architecture should therefore separate:

  1. Source obligation — the authoritative legal, contractual, standard, or policy text.
  2. Interpretation — the accountable determination of how it applies.
  3. Control objective — the required outcome.
  4. Control implementation — the technical and organizational mechanisms.
  5. Assessment procedure — how effectiveness is evaluated.
  6. Evidence — what demonstrates the result.
  7. Mapping — relationships to other frameworks or obligations.

Mappings are not equivalence proofs. One control may support multiple obligations, but satisfying the control does not automatically establish compliance with every mapped requirement. Legal conclusions remain the responsibility of qualified and accountable parties.

This separation allows implementations to evolve while preserving traceability. It also supports technology substitution when the required security, governance, evidence, and assurance properties remain intact.

15. Continuous GRC as a Cross-Cutting SGAEIA Property

Within SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture — Continuous GRC is a cross-cutting architectural property rather than a reporting layer added after execution.

Its purpose is to ensure that autonomous operation remains continuously constrained by approved governance context. The architecture therefore treats the following properties as inseparable:

  • bounded and revocable authority;
  • traceable governance intent;
  • risk-aware decision context;
  • continuous control assessment;
  • verifiable evidence;
  • drift-aware reassessment;
  • governed exception handling;
  • accountable human escalation; and
  • assurance that remains meaningful across cloud, edge, and distributed agent activity.

These are architectural responsibilities, not prescriptions for a particular internal service decomposition. SGAEIA is intentionally implementation-neutral regarding how organizations realize them, provided that the resulting system preserves the required security and governance properties.

Continuous GRC therefore functions as a constraint on the behavior of the architecture as a whole. It influences whether authority remains valid, whether risk assumptions remain current, whether evidence is sufficient, whether exceptions remain legitimate, and whether autonomous action may continue under changed conditions.

Figure 5 — Continuous GRC as a Cross-Cutting SGAEIA Property
Figure 5 — Continuous GRC as a Cross-Cutting SGAEIA Property. Bounded authority, governance context, continuous assurance, verifiable evidence, revocability, and adaptation to change must remain coherent across distributed autonomous operation. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

SGAEIA does not depend on one product or one deployment topology. Implementations may evolve or be substituted over time, but the governing properties must remain coherent and independently assessable.

16. SGAEIA Architectural Invariants

Continuous GRC in SGAEIA is governed by the following invariants:

  1. No policy without provenance. Every operational policy remains traceable to an approved normative source and accountable ownership.
  2. No autonomous action outside current governance context. Authority is necessary but not sufficient; applicable controls and runtime risk conditions must also be satisfied.
  3. No control claimed without an assessment basis. Every control has a defined basis for evaluation, supporting evidence, and accountable ownership.
  4. No compliance inferred from telemetry alone. Observations must be evaluated against applicable obligations and criteria.
  5. No silent policy divergence. Operational governance must remain consistent with approved policy, and material divergence must trigger governed reassessment.
  6. No exception without scope and expiry. Exceptions are bounded, attributable, reviewable, revocable, and linked to compensating expectations where required.
  7. No delegation that discards obligations. Delegated authority remains subject to every governance obligation that continues to apply.
  8. No high-impact action on stale governance state unless explicitly permitted by approved governance. Degraded or offline operation remains risk-bounded and no broader than connected operation.
  9. No evidence without identity and integrity. Evidence is attributable to authenticated producers and protected against undetected alteration.
  10. No assurance based solely on the governed component's own claims. High-impact controls require independent verification appropriate to risk.
  11. No drift without impact analysis. Material changes trigger reassessment of affected authority, controls, exceptions, and decisions.
  12. No automated remediation with unbounded authority. Automated response remains constrained, purpose-bound, attributable, and revocable.
  13. No framework mapping presented as automatic legal compliance. Mappings support traceability but do not replace accountable interpretation.
  14. No technology substitution that weakens invariant properties. Components may change only when security, governance, evidence, and assurance properties are preserved.

17. An Illustrative Multi-Agent Governance Scenario

Consider a distributed incident-response setting in which an autonomous system has already taken a defensive action against a suspected compromise. A static authorization model might treat the completed action as the end of the governance process. Continuous GRC does not.

After the action, new operational information may reveal that one of the assumptions behind the original decision has changed. The defensive action may have reduced cyber risk while simultaneously increasing service-availability risk. A dependency may have changed. A tool may no longer have the same assurance status. An exception may be required to restore service safely. New evidence may strengthen or weaken the original justification.

Continuous GRC treats these changes as governance events rather than merely operational telemetry. The system must be able to reassess whether the prior authority, controls, risk acceptance, and evidence remain sufficient for continued autonomous action.

A governed response may therefore become more restrictive, require stronger evidence, request accountable human judgment, introduce a bounded exception, or suspend further high-impact action until the relevant uncertainty is resolved.

The purpose of this scenario is not to prescribe a workflow. It illustrates a general principle: in an autonomous system, governance does not end when an action is executed. Governance continues for as long as the consequences, authority, dependencies, and risk conditions remain material.

18. Adoption Principles for Continuous GRC

Organizations do not need to automate every governance process at once. The safer objective is progressive adoption without losing traceability, accountability, or independent assurance.

Several principles can guide that adoption:

Start with accountability and inventory

Organizations should know which autonomous agents, models, tools, data sources, policies, controls, identities, and evidence producers participate in high-impact activity and who is accountable for them.

Prioritize high-impact governance boundaries

The earliest effort should focus on actions whose consequences justify stronger runtime governance, rather than attempting to automate every low-risk control uniformly.

Separate governance intent from agent behavior

Critical governance requirements should not depend solely on prompts, model cooperation, or the governed component's self-description.

Make evidence a design requirement

Evidence needed for high-impact decisions should be considered before deployment, with attention to provenance, integrity, freshness, retention, privacy, and independent review.

Automate where semantics are clear

Deterministic controls are good candidates for automation when their meaning is stable and their outcomes can be independently verified. Ambiguous governance judgments should not be forced into deterministic automation merely for speed.

Govern remediation as carefully as detection

A system that can detect risk but responds with unbounded autonomous authority creates a new source of risk. Automated response must remain constrained, attributable, and revocable.

Prefer interoperable assurance where practical

Open standards and portable evidence models can reduce dependence on proprietary governance silos when they preserve the semantics needed for agentic systems.

Exercise degraded and adversarial conditions

Governance should be evaluated not only under normal operation but also when evidence is incomplete, dependencies change, connectivity degrades, policies diverge, or assurance components fail.

Measure the governance system itself

Organizations should assess whether governance evidence is complete, controls remain effective, exceptions remain bounded, policy divergence is visible, and responses occur quickly enough without sacrificing assurance.

These are adoption principles rather than an implementation sequence. Different organizations may realize them using different technologies, architectures, and operating models.

19. Conclusion

Autonomous AI compresses the distance between decision and consequence. Governance that operates only through periodic documents and retrospective audits cannot reliably constrain machine-speed, distributed action.

Continuous GRC closes that gap by connecting approved objectives to executable policy, runtime risk evaluation, control assessment, evidence, exceptions, and governed response. It does not mean that machines determine legal compliance or replace accountable human judgment. It means that the operational system can continuously establish whether the conditions for autonomous action remain valid and can respond when they do not.

The central design rule is:

Continuous GRC does not mean continuously permitting autonomous action. It means continuously verifying whether the conditions for that action remain valid.

For agentic systems, this requires more than telemetry. Authority and obligations must travel together. Controls must be testable. Evidence must be attributable and verifiable. Drift must trigger impact analysis. Exceptions must expire. Offline operation must narrow. Remediation must itself be governed.

Without these properties, GRC becomes a delayed narrative about autonomous behavior. With them, governance becomes part of the architecture that shapes behavior while preserving accountability.

20. References

  1. Open Policy Agent. “OPA Management APIs and Architecture.” Official Documentation. https://www.openpolicyagent.org/docs/management-introduction ; Open Policy Agent. “Decision Logs.” Official Documentation. https://www.openpolicyagent.org/docs/management-decision-logs
  2. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, January 2023. https://doi.org/10.6028/NIST.AI.100-1
  3. National Institute of Standards and Technology. “AI RMF Core.” NIST AI Resource Center. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
  4. International Organization for Standardization. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. December 2023. https://www.iso.org/standard/42001
  5. Dempsey, K., Johnson, L. A., Scholl, M. A., Stine, K. M., Jones, A. C., Orebaugh, A., Chawla, N. S., and Johnston, R. Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. NIST Special Publication 800-137, September 2011. https://doi.org/10.6028/NIST.SP.800-137
  6. World Wide Web Consortium. PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-o/
  7. National Institute of Standards and Technology. “OSCAL Assessment Layer: Assessment Results Model.” Open Security Controls Assessment Language (OSCAL). https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-results/
  8. National Institute of Standards and Technology. “OSCAL Layers and Models.” Open Security Controls Assessment Language (OSCAL). https://pages.nist.gov/OSCAL/learn/concepts/layer/
  9. Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and Lasker, S. An Architecture for Trustworthy and Transparent Digital Supply Chains. RFC 9943, June 2026. https://doi.org/10.17487/RFC9943
  10. National Institute of Standards and Technology. “Measure.” NIST AI RMF Playbook. https://airc.nist.gov/airmf-resources/playbook/measure/
  11. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal of the European Union, July 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
  12. International Organization for Standardization. ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. February 2023. https://www.iso.org/standard/77304.html
  13. International Organization for Standardization. ISO/IEC 42005:2025 — Information technology — Artificial intelligence (AI) — AI system impact assessment. May 2025. https://www.iso.org/standard/42005
  14. National Institute of Standards and Technology. Security and Privacy Controls for Information Systems and Organizations. NIST Special Publication 800-53, Revision 5, September 2020, including updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5
  15. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, July 2024. https://doi.org/10.6028/NIST.AI.600-1

About the Author

Aridio Silva is an independent researcher based in Brazil working on the architecture, security, governance, and trustworthiness of autonomous and distributed Artificial Intelligence systems.

His research focuses on Agentic AI, Multi-Agent Systems, Edge AI, AI Security, Zero Trust, Security-by-Design, AI Governance, Spec-Driven Development, and continuous security assurance.

He is the creator and lead researcher of SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture, an open research initiative investigating architectural foundations for secure, governed, auditable, and trustworthy autonomous AI systems operating across distributed edge-cloud environments.

Research & Project Resources

SGAEIA — GitHub Repository
SGAEIA — Zenodo Research Artifact / DOI
ORCID — Aridio Silva
Google Scholar — Aridio Silva
GitHub — Aridio Silva
LinkedIn — Aridio Silva

Figures

Conceptual diagrams developed for SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture. © 2026 Aridio Silva. See the SGAEIA repository for applicable licensing and reuse terms.

License

Except where otherwise noted, the text and original conceptual diagrams in this article are licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).

Version 2.0 — September 15, 2026

This article has been substantially revised to sharpen the distinction between architectural principles and implementation-specific mechanisms. Version 2.0 preserves the central research arguments and SGAEIA architectural propositions while focusing the public presentation on technology-independent governance properties, invariants, and assurance requirements.

© 2026 Aridio Silva. You may share and adapt this work for any purpose, provided appropriate attribution is given. Software, source code, and technical artifacts in the SGAEIA repository remain subject to the license specified in that repository.

Autonomous AI. Governed by Design. Trusted by Evidence.

Series continuity

  1. From Edge AI to Governed Autonomous Edge Intelligence
  2. Why Autonomous AI Agents Need Bounded and Revocable Authority
  3. Zero Trust for Multi-Agent AI Systems
  4. Authenticated Delegation Between Autonomous AI Agents
  5. Continuous GRC for Agentic AI
  6. Evidence-as-Code: Making AI Governance Verifiable
  7. Security-by-Design for Distributed Agentic AI
  8. SGAEIA: A Reference Architecture for Secure Governed Autonomous Edge Intelligence

Suggested citation

Silva, Aridio. (2026). Continuous GRC for Agentic AI (Version 2.0). Zenodo. https://doi.org/10.5281/zenodo.22728227

Zenodo is the persistent source for files, version, license, and citation data.