Enhanced Agentic Security Architecture
A State-of-the-Art Enterprise Architecture for Governing

Models, Agents, Harnesses, Authority, Actions, and Consequences

Dennis C. Hayes
Chairman and CEO, SpartansFirst
Editor, spartansfirst.org Technology Blog
2026 Third Quarter Initial Release Publication, August 24, 2026

Research Basis, Method, and Purpose

The Enhanced Agentic Security Architecture is a researched, vendor-neutral architecture intended to describe how enterprise security must evolve as artificial intelligence progresses from producing information and recommendations to operating as an active software participant capable of reasoning, planning, acquiring capabilities, using tools, communicating with other agents, exercising delegated authority, and initiating actions that change enterprise systems and business state.

The research was conducted through three complementary sources of evidence.

First, national standards, government cybersecurity research, and emerging AI-agent guidance were reviewed, with particular attention to the National Institute of Standards and Technology’s work concerning AI-agent security, identity and authorization, interoperability, cybersecurity risk, adversarial testing, vulnerability information, least privilege, and continuous security. NIST’s 2026 AI-agent work is especially important because it recognizes that existing cybersecurity principles remain applicable while the autonomous, tool-using, delegated characteristics of agents create additional security problems requiring new controls.

Second, recent academic and independent research through August 22, 2026 was examined. This research provides important architectural insights that are emerging faster than traditional standards-development processes. The papers reviewed address agent harness engineering, runtime contracts, tracked capabilities, dynamic skills, self-evolving agents, agent-environment interaction, behavioral security, tool orchestration, trajectory analysis, adversarial evaluation, multi-layer red teaming, and continuous deployment assurance. Where a distinctive architectural concept is materially derived from or strengthened by this research, the source is identified when the concept is introduced.

Third, technical architectures, documentation, security systems, governance products, and agentic platforms from fourteen major enterprise technology and cybersecurity companies were examined:

1. Amazon Web Services
2. Microsoft
3. Google Cloud
4. IBM
5. ServiceNow
6. Oracle
7. SAP
8. Salesforce
9. OneTrust
10. Databricks
11. NVIDIA
12. Palo Alto Networks
13. Palantir Technologies
14. Harness

The vendor analysis was conducted differently from the academic research. It was used to determine which security mechanisms are already being implemented in enterprise environments, which capabilities recur across several implementations, and which distinctive capabilities could strengthen a comprehensive architecture.

This paper is not a vendor comparison, product evaluation, or description of any particular commercial system. Vendor capabilities have therefore been abstracted into vendor-neutral architectural functions and are not attributed to individual vendors throughout the architecture. The vendor sources are identified collectively in the references.

The result combines:

National Standards and Government Direction → Academic Research → Enterprise Implementation Experience → Architectural Synthesis.

The objective is a state-of-the-art view, as of August 2026, of an enterprise architecture capable of making maximum practical use of the reasoning and adaptability of probabilistic AI while surrounding consequential activity with deterministic security constraints.

The governing principle is:

Probabilistic intelligence should be allowed to reason, plan, adapt, and propose. Deterministic security mechanisms should independently constrain, authorize, observe, and verify consequential action.



1. From the Probabilistic Model to the Governed Agentic System

The architecture begins by defining correctly what must be secured.

A foundation model is a probabilistic computational model capable of functions such as language understanding, generation, reasoning, planning, classification, prediction, coding, and multimodal interpretation. Its probabilistic nature is important: given complex circumstances, it can generate solutions that were not explicitly programmed in advance.

That capability is the source of much of the value of agentic AI.

It is also why the model cannot itself be the final enterprise security authority.

A conventional deterministic security control evaluates explicit conditions and produces constrained outcomes. An authorization system can determine that a particular identity may perform a specified action against a particular resource. A transaction system can refuse payments above a defined amount. A network control can prevent communication with an unauthorized destination.

The model and the deterministic control therefore perform fundamentally different functions.

Probabilistic Model → Determines what might or should be done.

Deterministic Security Control → Determines what is permitted to be done.

An agent is created when model capability is surrounded by additional components that allow the model to pursue an objective and interact with an environment.

The complete agentic security object can be represented as:

Model + Instructions + Context + Memory + Retrieval + Skills + Tools + Harness + Identity + Authority + Policies + Environment + Runtime State → Operating Agentic System.

Recent harness research supports this broader system definition. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents describes agent capability as emerging from a model-harness-environment system rather than from the model alone. HarnessRisk subsequently demonstrates that security characteristics can change through harness configuration even when the underlying model remains unchanged.

The operating chain is therefore:

Human/System Objective → Agent → Harness → Model/Reasoning → Context/Memory → Skills/Tools → External Systems → Action → Enterprise Effect.

This establishes the first principle of the architecture:

The security boundary must surround the complete agentic system, not merely the language model.

The Agent Harness

The agent harness is the deterministic and programmatic runtime structure surrounding the model that converts model reasoning into continuing execution.

The harness can manage context construction, memory, retrieval, model selection, tool availability, skill acquisition, state, execution loops, retries, permissions, communications, evaluation, and termination.

Its position is critical:

Objective → Harness → Context Construction → Model Invocation → Tool/Skill Orchestration → State Management → Evaluation → Next Action.

The harness is therefore treated as a first-class security boundary.

It must be:
 Identifiable → Versioned → Inventoried → Integrity-Protected → Policy-Controlled → Observable → Testable → Auditable.

A harness change is consequently a potentially security-significant change even when the model remains identical.

Agent Safety Should Be a Runtime Contract strengthens this concept by arguing that safety should be enforced in the runtime surrounding the model rather than relying solely upon training-time alignment.

The Agentic Security Control Plane

Surrounding the agent and harness is the Agentic Security Control Plane: the logical collection of independently enforceable security mechanisms governing the agent.

It can include identity infrastructure, policy engines, gateways, authorization services, credential brokers, application controls, data controls, network controls, transaction systems, runtime monitors, logging systems, and security analytics.

Its basic sequence is:

Agent Reasoning → Proposed Action → Security Control Plane → Authorization Decision → Execution → Verification → Evidence.

This establishes a deliberate separation between Reasoning Authority and Execution Authority.

The model may conclude:

“This is the appropriate action.”

The control plane independently determines:

“This agent is permitted to perform that action under these circumstances.”

The architecture therefore creates deterministic controls around probabilistic intelligence:

Probabilistic Reasoning → Deterministic Policy Evaluation → Controlled Enterprise Effect.



2. Knowing the Agent: Identity, Registry, Composition, Capabilities, and Evolution

Once the complete agentic system is recognized, the enterprise must determine which agents exist, what constitutes them, what they can do, and how those characteristics change.

First-Class Agent Identity

A first-class agent identity is an independently recognizable security identity assigned to a consequential agent.

The agent should not disappear behind the identity of the human who initiated it or the application in which it operates.

The accountability chain becomes:

Human Initiator → Agent Identity → Delegated Authority → Tool/Application → Action.

NIST’s 2026 agent identity and authorization work explicitly identifies identification, authorization, auditing, and non-repudiation as important requirements for software and AI agents.

The Authoritative Agent Registry

The Agent Registry is the authoritative inventory of agents that the enterprise expects and permits to exist.

It can maintain:

Agent Identifier → Organizational Owner → Responsible Sponsor → Approved Purpose → Risk Classification → Model/Harness Configuration → Deployment → Authorized Capabilities → Applicable Policies → Assurance State.

The Registry also maintains lifecycle state:

Development → Evaluation → Approved → Production → Restricted → Suspended → Quarantined → Retired.

The architecture then compares the declared environment with reality:

Declared Agent Population ↔ Observed Agent Population.

An operating agent that cannot be reconciled with an authorized registry entry is a Shadow Agent.

The control loop becomes:

Discover → Identify → Register → Classify → Govern → Observe → Reconcile.

Agent Bill of Materials

Knowing that an agent exists is insufficient. The enterprise must know what constitutes and influences it.

The Agent Bill of Materials, or ABOM, is the structured description of the components and dependencies materially influencing a particular agent.

It can include:

Agent → Model → Model Version → Instructions → Prompt Configuration → Harness → Software Dependencies → Skills → Tools → MCP Servers → APIs → Memory → Retrieval Services → Data Sources → Policies → Credential Mechanisms → External Services → Other Agents.

The architecture distinguishes:

SBOM → Conventional software components.

AI BOM → Models and AI-specific artifacts.

ABOM → Components and relationships constituting or influencing a particular agentic actor.

These inventories should be linked rather than duplicated.

The ABOM also becomes dynamic.

Declared ABOM → Runtime Observation → Reconciliation → Difference Analysis → Security Decision.

This is Continuous ABOM Reconciliation.

A difference between approved and observed composition becomes Agentic Configuration Drift:

Approved Configuration ↔ Runtime Configuration → Drift → Evaluate → Correct / Authorize / Contain.

Capability Graph

Composition does not fully describe consequence.

The Capability Graph represents what becomes possible through the relationships among an agent and its resources:

Agent → Identity → Permissions → Skills → Tools → MCP → APIs → Applications → Data → Credentials → Other Agents → Business Actions.

This supports Composite Capability Analysis.

For example:

Read Confidential Information + Create File + External Communication → Potential Exfiltration Capability.

Individually acceptable permissions can therefore produce unacceptable composite authority.

The 2026 paper Securing Agents With Tracked Capabilities reinforces this concept by using tracked capabilities to regulate access to resources and effects and constrain information flow.

The architecture consequently supports:

Requested Operation → Required Capability → Capability Validation → Controlled Effect.

Dynamic Skills and Capability Presence

Capabilities increasingly may be acquired dynamically rather than permanently installed.

The @skills research provides an important basis for distinguishing different capability states:

Capability Exists → Approved → Discoverable → Retrievable → Present → Activated → Authorized for Current Task.

These states must not be confused.

The corresponding acquisition sequence is:

Skill Discovery → Provenance → Integrity → Version → Vulnerability → Dependency → Purpose → Authorization → Activation.

The governing rule is:

Capability availability does not constitute capability authority.

Self-Evolving Agents

SHAPER and research describing self-evolving agents as dynamic graph transformations demonstrate that an agent can change its skills, harness, memory, workflows, tools, or relationships without changing the underlying model weights.

Therefore:

Evolution → Composition Change → Capability Change → Behavioral Change → Attack-Surface Change → Authority Implication → Consequence Change.

The architecture consequently establishes:

Self-evolution must never imply self-authorization.

The controlled evolution process becomes:

Proposed Evolution → Isolated Candidate → ABOM Update → Capability Analysis → Evaluation → Security Testing → Policy Assessment → Approval → Controlled Promotion → Runtime Observation → Reassurance.

The corresponding dynamic graph process is:

Current Agent Graph → Proposed Transformation → Security Analysis → Authorized Graph → Runtime Reconciliation.



3. Purpose, Authority, Delegation, Tools, and Governed Enterprise Actions

Knowing what an agent can technically do is different from determining what it should be allowed to do.

The architecture therefore distinguishes Capability from Authority.

Purpose-Bound Security and the Authority Envelope

Purpose-Bound Security means that authority and expected behavior are anchored to the legitimate purpose for which an agent was approved.

The basic relationship is:

Agent Identity → Approved Purpose → Permitted Capabilities → Permitted Actions.

The architecture then introduces the Authority Envelope: the complete bounded set of conditions within which an agent may legitimately operate.

Authorization becomes:

Identity + Purpose + Intent + Delegation + Capability + Resource + Context + Risk → Authority Decision.

This creates Intent-Aware Authorization.

Access is not evaluated merely according to who the actor is, but also according to what it is attempting to accomplish and why.

Human Delegation

A human assigning work to an agent should not automatically transfer all of the human’s privileges.

Instead:

Human Authority → Task Definition → Delegated Authority Envelope → Agent.

The delegated envelope can specify:

Task → Resources → Actions → Duration → Transaction Limits → Data Boundaries → Approval Requirements → Revocation Conditions.

This creates Task-Scoped Delegation and reduces Agent-Mediated Privilege Escalation.

A request therefore becomes:

Requester Identity → Requested Action → Requester Authority + Agent Authority + Purpose → Permit/Deny.

Least Privilege, Least Tool Surface, and Least Action Surface

Traditional Least Privilege gives an actor only necessary permissions.

Agentic systems require two extensions.

Least Tool Surface exposes only tools necessary for the approved purpose:

Approved Purpose → Required Functions → Minimum Tool Set.

But even tool access can be too broad.

The architecture therefore adds Least Action Surface, which exposes only the actual business effects required.

The progression is:

Least Privilege → Least Tool Surface → Least Action Surface.

Tool, API, MCP, and Inter-Agent Security
 Tools are security-significant because they transform reasoning into capability.

Every significant tool relationship should establish:

Tool Identity → Provenance → Version → Integrity → Permissions → Credential Requirements → Inputs → Outputs → Network Destination → Dependencies → Vulnerabilities → Permitted Operations.

MCP creates an additional distinction:

Authority to Reach MCP Server ≠ Authority to Invoke Every MCP Tool.

Therefore:

Agent → MCP Server Authorization → Tool Discovery → Individual Tool Authorization → Invocation.

The architecture also establishes:

Trusted Tool ≠ Trusted Tool Result.

A legitimate search system, email service, website, database, or API can return attacker-controlled information.

Inter-agent communication similarly requires:

Agent A → Identity + Authority + Purpose + Provenance → Agent B → Delegated Task → Controlled Action.

Authority and provenance must survive the complete delegation chain.

Governed Business Actions

A Governed Business Action represents a meaningful enterprise effect as an explicit security object.

Examples include creating a requisition, issuing a refund, modifying a configuration, approving a workflow, initiating payment, or updating a customer record.

Its structure can be:

Actor → Governed Action → Parameters → Business Rules → Authorization → State Change.

Each action can define eligible actors, required information, permitted parameters, transaction ceilings, separation-of-duty requirements, and human approvals.

Risk-Tiered Autonomy

Autonomy should not be assigned once to an entire agent.

Instead:

Agent + Action + Context + Consequence → Autonomy Level.

The same agent may therefore operate:

Autonomously → With Increased Monitoring → With Human Approval → Proposal-Only → Prohibited

depending upon the particular action.



4. From Reasoning to Action: Proposed Actions, Runtime Contracts, and Deterministic Enforcement

The transition from reasoning to consequence is one of the most important boundaries in the architecture.

Proposed Action Object

A Proposed Action Object converts an agent’s probabilistic conclusion into a structured object that deterministic security systems can evaluate.

It can contain:

Agent Identity → Objective → Proposed Action → Target → Parameters → Required Authority → Supporting Evidence → Provenance → Expected Effect.

The Proposed Action Boundary then operates as:

Reason → Propose → Validate → Authorize → Execute → Verify → Record.

This prevents a model-generated decision from automatically becoming an enterprise action.

Runtime Contracts

A Runtime Contract is an enforceable set of invariants governing what must or must not occur during agent execution.

The concept is strongly supported by Agent Safety Should Be a Runtime Contract.

Runtime Contracts can govern:

Accessible Resources → Callable Tools → Permitted Data Flows → Allowed Destinations → Transaction Limits → Forbidden Action Combinations → Required Approvals → Resource Limits → Required Evidence.

Two types of control are particularly important.

Preventive Runtime Control:

Proposed Operation → Runtime Contract → Permit/Block.

Evidential Runtime Control:

Required Security Condition → Independent Evidence → Verification → Execution/Completion.

This changes security from:

“The agent was instructed not to do this.”

to:

“The architecture prevents this operation.”

And from:

“The agent says it performed the required check.”

to:

“Independent evidence proves the check occurred.”


5. Information, Memory, Credentials, Environment, and Containment

Agent reasoning depends upon external information and infrastructure. Those dependencies therefore become part of the security architecture.

Data and Retrieval Security

The architecture establishes two fundamental distinctions:

Retrieved Information ≠ Authorized Instruction.

Accessible Information ≠ Trustworthy Information.

Information entering agent context should therefore be evaluated for:
 Provenance → Integrity → Classification → Freshness → Authoritative Status → Quality.

Semantic Integrity extends beyond byte-level integrity to ask whether information retains trustworthy meaning, context, and interpretation.

The architecture then introduces Data-Quality-Bound Authority:

Evidence Quality Falls → Assurance Falls → Authority Falls → Supervised/Human Review.

Memory Security

Memory Security treats persistent agent memory as security-sensitive state.

Controls cover:

Memory Provenance → Write Authority → Read Scope → Integrity → Classification → Retention → Expiration → Revalidation → Deletion.

The lifecycle becomes:

Memory Creation → Validation → Use → Revalidation → Expiration/Deletion.

Memory isolation prevents information acquired in one context from automatically acquiring authority in another.

Credential Isolation and Brokerage

Reusable secrets should remain outside model-visible context wherever practical.

Credential Brokerage separates credential possession from credential use:

Agent Request → Identity → Purpose → Authorization → Credential Broker → Scoped Authority → Tool Invocation.

Credentials can then be:

Short-Lived → Resource-Scoped → Purpose-Bound → Action-Bound → Revocable → Auditable.

Environment Integrity

EnvHarness demonstrates the significance of the agent-environment relationship. Although developed for learning environments, its implications extend to security: changing the environment can change agent behavior.

Environment Integrity therefore protects:

Runtime + Container + Libraries + Network + Tool Endpoints + Model Endpoints + Policy Services + Credentials + Dependencies.

Runtime reality is compared with the approved environment:

Expected Environment ↔ Observed Environment → Drift → Security Evaluation.

Model-Path Integrity

An agent reaching an approved model through an unauthorized path may bypass critical security controls.

The expected path may be:

Agent → Governed Gateway → Approved Model.
 The architecture therefore performs:

Expected Model Path ↔ Observed Model Path → Drift → Restrict/Contain.

Assumed Agent Compromise

The architecture explicitly assumes that an agent may eventually be compromised or make an unsafe decision.

Potential causes include prompt injection, indirect prompt injection, malicious tools, poisoned skills, poisoned memory, vulnerable software, compromised dependencies, credential theft, and model substitution.

Therefore:

Security must remain capable of limiting damage even when the agent itself can no longer be trusted.

Agent Containment Boundary

The Agent Containment Boundary independently limits:

Process → Filesystem → Network → Credentials → Tools → Data → Transactions → Communications → Resource Consumption.

Controls include sandboxing, process isolation, filesystem isolation, network egress restrictions, credential isolation, quotas, rate limits, budgets, and termination conditions.

Resource Authority recognizes that agents can consume tokens, compute, APIs, storage, bandwidth, money, and scarce human-review capacity.

The control sequence becomes:

Agent Operation → Resource Meter → Limit/Policy → Continue / Throttle / Stop.


6. Behavioral Security, Trajectories, and Adversarial Validation

Static identity and configuration controls cannot determine whether an approved agent is behaving safely.

The architecture therefore adds behavioral and trajectory security.

Purpose-Bound Behavioral Baseline

A Purpose-Bound Behavioral Baseline describes legitimate operating patterns associated with an agent’s approved purpose:

Approved Purpose → Expected Tools → Expected Sequences → Expected Data Sources → Expected Destinations → Expected Transactions → Expected Privilege Use → Expected Resource Consumption.

Professor Wenke Lee’s body of behavioral cybersecurity research provides an important foundation for evaluating behavior and multistage activity rather than relying exclusively on known malicious signatures.
 Behavioral Drift

Runtime activity is compared against legitimate expected behavior:

Expected Purpose-Bound Behavior ↔ Observed Behavior → Drift → Risk Evaluation → Response.

Behavioral security asks:

Is this actor behaving consistently with its authorized purpose?

rather than merely:

Does this activity match a known malicious signature?

Agentic Trajectory

An Agentic Trajectory is the ordered sequence through which an agent progresses from objective to outcome.

Objective → Observation → Retrieval → Decision → Tool → Result → State Change → Next Decision → Action → Outcome.

The trajectory becomes important because individually legitimate actions can combine into unsafe outcomes.

For example:

Retrieve Confidential Data → Create File → Identify External Destination → Send File.

Several recent research lines converge on this requirement. ProofAgent Harness uses adversarial multi-turn behavioral traces. Governing Execution Risk in Agentic AI Systems treats execution risk as a trajectory-level phenomenon. Towards Risk-free AI Agent Deployment emphasizes trajectory analysis for debugging, testing, and deployment assurance.

The architecture therefore makes Trajectory Security Analysis a first-class function.

Tool-Orchestration Security

Tool safety cannot be determined exclusively by testing tools independently.

A dangerous condition may emerge from:

Tool A → Tool B → Tool C → Unsafe Composite Effect.

Tool-orchestration security evaluates those combinations.

Behavioral Constraint Synthesis

When an unsafe trajectory is discovered, the architecture converts it into security knowledge:

Unsafe Trajectory → Reproduce → Attribute Cause → Identify Missing Constraint → Create Constraint → Test → Deploy → Monitor → Regression Test.

This creates the Production-to-Security Learning Loop:

Production Experience → Security Knowledge → New Constraint → Regression Test → Improved Assurance.

Multi-Layer Agent Red Teaming

Recent multi-layer agent red-teaming research demonstrates that agent security testing must extend beyond the model.

The test sequence becomes:

Infrastructure → Protocol/MCP → Tool → Skill → Agent Behavior → Model → End-to-End Trajectory.

Testing should include direct and indirect prompt injection, tool poisoning, skill poisoning, memory poisoning, privilege escalation, unauthorized delegation, credential theft, data exfiltration, MCP manipulation, unsafe tool chaining, policy bypass, model-path bypass, resource exhaustion, persistence, lateral movement, and long-horizon multistage attacks.

A successful finding enters:

Attack → Observe → Reproduce → Diagnose → Correct → Constraint → Regression Test → Revalidate → Deploy.

7. Blast Radius, Cascade Horizon, Consequence, Vulnerabilities, and the Agentic Supply Chain

The architecture must not only prevent attacks. It must limit what happens when prevention fails.

Blast-Radius Engineering

Blast Radius is the maximum direct scope of systems, data, identities, transactions, resources, or business operations that an agent, compromised agent, erroneous action, or exploited component can materially affect before independent controls stop further direct effects.

Blast-Radius Engineering deliberately minimizes that reach:

Identify Capability → Determine Maximum Direct Reach → Evaluate Consequence → Introduce Boundaries → Recalculate Reach → Minimize Acceptable Blast Radius.

Least privilege, task-scoped delegation, Least Tool Surface, Least Action Surface, segmentation, credential brokerage, transaction ceilings, sandboxing, network restrictions, rate limits, and independent authorization all contribute.

The architecture also defines Resource-Consumption Blast Radius: the maximum compute, token, API, storage, network, financial, or human-review resource a runaway or compromised agent can consume.

Cascade Horizon

Cascade Horizon describes something different:

The extent through which the consequences of an initiating agentic action, error, compromise, or failure can propagate through dependent systems, information flows, transactions, agents, and business processes over time.

The propagation chain may be:

Agent Action → Immediate State Change → Dependent Process → Secondary Effect → Additional Dependencies → Ultimate Consequence.

Therefore:

Blast Radius → Direct Effect.

Cascade Horizon → Propagated Consequence.

Consequence-Aware Security

For sufficiently consequential operations, the architecture evaluates anticipated effects before execution.

A Consequence Sandbox is a simulation, digital twin, workflow representation, or other controlled model of relevant enterprise state.

The sequence becomes:

Proposed Action → Simulated State Change → Dependency Propagation → Predicted Cascade → Risk Evaluation → Authorization.

Authorization therefore evolves toward:

Identity + Authority + Context + Predicted Consequence → Permit / Approve / Escalate / Deny.

Agent-Aware Vulnerability Management

Traditional vulnerability severity does not capture the enterprise authority of the affected agent.

The architecture therefore creates Agentic Exploitability Context:

Vulnerability → Component → SBOM/AIBOM/ABOM → Agent → Capability Graph → Authority → Attack Path → Business Process → Blast Radius → Cascade Horizon.

Prioritization becomes:

Technical Severity + Reachability + Exploitability + Agent Authority + Data Sensitivity + Tool Access + Business Criticality + Consequence → Remediation Priority.

The architecture distinguishes:

Potential Attack Path → Architecturally possible.

Validated Attack Path → Demonstrated through controlled adversarial testing.

The validation sequence becomes:

Potential Path → Controlled Attack → Demonstrated Reachability → Validated Attack Path.

Agentic Supply-Chain Security

The agentic supply chain extends beyond conventional software:

Software → Model → Prompt → Harness → Skill → Tool → MCP Server → Data → Retrieval Source → Memory → External Service → Other Agent.
 Each significant artifact or relationship requires appropriate:

Identity → Provenance → Version → Integrity → Approval State → Vulnerability State → Dependency Relationship → Runtime Verification.

The architecture therefore continuously asks:

What can influence this agent’s behavior right now?

8. Lifecycle Governance, Evidence, Continuous Assurance, and Dynamic Authority

All preceding controls must remain effective as agents and environments change.

Governed Agent Development Lifecycle

The complete lifecycle is:

Define → Register → Compose → Build → Evaluate → Security Test → Adversarially Test → Assure → Approve → Deploy → Observe → Reevaluate → Change → Reassure → Remediate → Retire.

Models, prompts, instructions, harnesses, skills, tools, MCP relationships, permissions, policies, memory configurations, and dependencies are security-significant artifacts and should be appropriately versioned.

Agentic Assurance Gates

Promotion into more consequential environments passes through assurance gates:

Development → Evaluation Gate → Security Gate → Adversarial Gate → Assurance Gate → Production.

A material change triggers:

Material Change → Assurance Reduced/Invalidated → Reevaluate → Reauthorize.

Security Regression Testing

A discovered vulnerability or behavioral failure should become a durable test:

Failure → Root Cause → Correction → Regression Test → Future Assurance.

Decision-to-Effect Lineage

Decision-to-Effect Lineage preserves the complete chain explaining how an enterprise consequence occurred:

Objective → Human Initiator → Agent Identity → Purpose → Delegated Authority → Context/Provenance → Model/Harness State → Trajectory → Tool Calls → Proposed Action → Policy Decision → Approval → Execution → Enterprise State Change → Downstream Consequence.

Evidence should come from independent systems where possible:

Identity Provider → Policy Engine → Gateway → Network → Tool → Application → Transaction System → Database → Security Telemetry.
 The architecture distinguishes:

Agent Explanation = Useful Evidence.

Independent Execution Evidence = Authoritative Evidence.

This supports auditability, accountability, incident investigation, debugging, compliance, and non-repudiation.

Continuous Agentic Assurance

Continuous Agentic Assurance is the ongoing evidence-based determination that an agent remains within its approved security, behavioral, transactional, resource, and consequence boundaries.

Its evidence can include:

Registry + Identity + ABOM + Capability Graph + Vulnerability State + Environment + Behavioral State + Trajectory Evidence + Runtime Contract Compliance + Adversarial Results + Transaction Outcomes + Resource Consumption → Current Assurance State.

This creates Dynamic Assurance rather than permanent trust.

Authority can then change:

Normal Autonomous Operation → Restricted Autonomy → Increased Monitoring → Supervised Operation → Proposal-Only → Quarantine → Suspension.

When evidence becomes insufficient, Fail-Safe Authority Reduction applies:

Insufficient Evidence / Unexpected State → Reduce Authority → Supervise / Proposal-Only / Quarantine.

Continuous Control Loops

The architecture contains several interconnected continuous loops.

Discovery-to-Governance Loop:
Discover → Identify → Register → Classify → Govern → Observe → Reconcile.

Vulnerability-to-Consequence Loop:
New Vulnerability → Locate Component → Identify Agents → Determine Reachability → Determine Authority → Calculate Blast Radius → Evaluate Cascade Horizon → Prioritize Response.

Evolution-to-Assurance Loop:
Agent Evolves → Composition Changes → Capability Changes → Reevaluate → Test → Update Assurance → Adjust Authority.

Behavior-to-Control Loop:
Behavior → Trajectory → Anomaly/Failure → Root Cause → Constraint → Regression Test → Runtime Enforcement.

General Security Feedback Loop:
Observe → Detect → Analyze → Learn → Constrain → Test → Reauthorize → Observe.

Emergency Revocation and Retirement
 When necessary, the enterprise must be capable of immediately revoking credentials, disabling tools, terminating sessions, suspending transactions, restricting communications, or quarantining an agent.

Retirement is also a security process:

Retire Agent → Revoke Identity → Revoke Credentials → Remove Tool/API Access → Resolve Memory/Data → Update Registry/ABOM → Verify Absence.

An agent should not leave behind orphaned authority.


Comprehensive Summary

The Enhanced Agentic Security Architecture reflects a fundamental change in enterprise computing.

Traditional software generally operates within procedures substantially determined when the software is developed. Agentic AI can instead receive an objective, interpret circumstances, determine intermediate steps, acquire information and capabilities, select tools, interact with other agents, and construct an execution trajectory that was not completely predetermined.

That makes agentic AI useful precisely because it is not entirely deterministic.

The architectural challenge is therefore not to make the reasoning model deterministic. Doing so would sacrifice much of the capability that makes the technology valuable.

The solution is to place probabilistic reasoning inside a deterministic security structure.

The model reasons.

The harness operationalizes that reasoning.

The Agent Registry establishes which agents should exist.

The ABOM establishes what constitutes them.

The Capability Graph determines what they can potentially accomplish.

Purpose establishes why they exist.

The Authority Envelope determines what they may actually do.

Least Privilege, Least Tool Surface, and Least Action Surface progressively minimize unnecessary authority.

The Proposed Action Boundary separates reasoning from consequence.

Runtime Contracts enforce invariants independently of model intention.

Data, memory, credentials, and environment controls protect the information and infrastructure influencing the agent.
 Behavioral Security evaluates whether the agent remains consistent with its legitimate purpose.

Trajectory Security determines whether individually legitimate operations combine into unsafe behavior.

Adversarial validation attacks the assumptions underlying those controls.

Containment assumes some defenses will eventually fail.

Blast-Radius Engineering limits direct damage.

Cascade Horizon determines how far consequences can propagate.

Consequence-Aware Security incorporates those downstream effects into authorization.

Agent-Aware Vulnerability Management connects technical weaknesses to actual enterprise authority and consequence.

Supply-chain security determines everything capable of influencing the agent.

Decision-to-Effect Lineage preserves independent evidence explaining consequential activity.

Continuous Agentic Assurance determines whether current evidence continues to justify current authority.

The complete architecture therefore operates as:

Discover the Agent → Identify It → Register It → Determine Its Composition → Reconcile Its ABOM → Map Its Capabilities → Establish Its Purpose → Bound Its Authority → Govern Delegation → Minimize Its Tools → Minimize Its Actions → Protect Its Data → Protect Its Memory → Isolate Its Credentials → Verify Its Environment → Enforce Runtime Contracts → Evaluate Proposed Actions → Authorize Consequential Execution → Observe Its Behavior → Analyze Its Trajectory → Capture Independent Evidence → Detect Vulnerabilities and Drift → Test Adversarially → Assume Compromise → Contain Failure → Engineer Blast Radius → Analyze Cascade Horizon → Learn From Outcomes → Update Constraints → Reassess Assurance → Dynamically Adjust Authority → Repeat Continuously.

At the highest architectural level, this can be reduced to:

Current Evidence → Current Assurance → Current Authority.

That relationship is the central operating principle of the Enhanced Agentic Security Architecture.

It allows enterprise organizations to make increasingly sophisticated use of AI reasoning without equating intelligence with unrestricted authority.



 

References

I. National Standards, Government, and Foundational Sources

1.1 National Institute of Standards and Technology. Request for Information Regarding Security Considerations for Artificial Intelligence Agent Systems. Docket NIST-2025-0035, January 2026.

1.2 Riggs, Jared; Hamin, Maia; Perry, Neil; Edelman, Benjamin; and Cihon, Peter. Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents. NIST Trustworthy and Responsible AI 800-5, May 18, 2026.

1.3 National Institute of Standards and Technology. AI Agent Standards Initiative. Center for AI Standards and Innovation, February 2026.

1.4 Booth, Harold; Fisher, William; Galluzzo, Ryan; and Roberts, Joshua. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. Initial Public Draft Concept Paper. NIST National Cybersecurity Center of Excellence, February 2026.

1.5 National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence: Cyber AI Profile. NIST IR 8596, Initial Preliminary Draft.

1.6 NIST Center for AI Standards and Innovation. Insights into AI Agent Security from a Large-Scale Red-Teaming Competition. March 2026.

1.7 National Institute of Standards and Technology. National Vulnerability Database. Continuing vulnerability-information infrastructure.

1.8 Vassilev, Apostol. Robust AI Security and Alignment: A Sisyphean Endeavor? IEEE Security & Privacy, 2026.



II. Academic and Independent Research

2.1 Odersky, Martin; Zhao, Yaoyu; Xu, Yichen; Bračevac, Oliver; and Pham, Cao Nguyen. “Securing Agents With Tracked Capabilities.” Proceedings of the ACM Conference on AI and Agentic Systems, 2026. DOI: 10.1145/3786335.3813127.

2.2 Zhong, Hailin, and Zhu, Shengxin. AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents. arXiv:2605.13357, May 2026.

2.3 Bousetouane, Fouad. ProofAgent Harness: Open Infrastructure for Adversarial Evaluation of AI Agents. arXiv:2605.24134, May 2026.

2.4 Yang, Yong; Zheng, Xing; Wu, Huiyu; et al. Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming. arXiv:2606.31227, June 2026.

2.5 Pasquini, Dario; Bazyli, Michal; Fedynyshyn, Taras; and Sorokin, Artem. Red-Teaming the Agentic Red-Team. arXiv:2606.24496, 2026.

2.6 Zhu, Zhihao, and Yang, Yi. Governing Execution Risk in Agentic AI Systems: A Trajectory-Guided Framework for Red Teaming. arXiv:2608.04018, August 2026.

2.7 Ng, Albus W.; Han, Yi; Zhang, Jusheng; and Wang, Wenhao. Agent Safety Should Be a Runtime Contract. arXiv:2608.11274, August 2026.

2.8 Wang, Peidong; Ma, Zhiming; Chang, Ying; et al. Self-Evolving Embodied Agents via Skill-Harness Evolution (SHAPER). arXiv:2608.11350, August 2026.

2.9 Yin, Li; Li, Zhi; Shi, Zhan; Zhang, Haoran; Seong, Haebin; et al. @skills: Attention is all you have. arXiv:2608.12610, August 2026.

2.10 Huo, Yintong; Pan, Rangeet; and Roychoudhury, Abhik. Towards Risk-free AI Agent Deployment. arXiv:2608.16411, August 2026.

2.11 Bai, Yajing; Duan, Jinhao; Peng, Jie; et al. HarnessRisk: A Lifecycle-Oriented Benchmark for Agent Harness Safety. arXiv:2608.17597, August 2026.

2.12 Xu, Yuanyuan; Zhang, Wenjie; Chen, Yin; Lin, Xuemin; and Zhang, Ying. Self-Evolving Agents as Dynamic Graph Transformation: A Survey and New Perspective. arXiv:2608.18104, August 2026.

2.13 Huang, Chengsong; Wang, Zifeng; Han, Rujun; et al. EnvHarness: Awakening Static Worlds for Agent Learning. arXiv:2608.19880, August 2026.

2.14 Chen, Jizhou, and Cong, Samuel Lee. AgentGuard: Repurposing Agentic Orchestrator for Safety Evaluation of Tool Orchestration. arXiv:2502.09809, 2025.

2.15 Lee, Wenke, and collaborators, Georgia Institute of Technology. Research concerning behavioral intrusion detection, anomaly detection, malware behavior, multistage attacks, adversarial machine learning, and AI-enabled cybersecurity.

2.16 NSF AI Institute for Agent-Based Cyber Threat Intelligence and Operation (ACTION). Research concerning intelligent cyber agents, cyber threat intelligence, autonomous defensive operation, and human-agent collaboration.



III. Enterprise Vendor Technical Sources Reviewed

The following companies’ technical architectures, security guidance, documentation, white papers, or product materials were examined. Their capabilities were abstracted into the architecture and intentionally not attributed individually in the body.

3.1 Amazon Web Services (AWS). Security for Agentic AI on AWS; Agentic AI Security Scoping Matrix; agentic governance, identity, tool, MCP, runtime, and security guidance.

3.2 Microsoft. Agentic AI security and governance maturity guidance; Copilot Studio security and governance; agent identity, lifecycle, authorization, and enterprise governance documentation.

3.3 Google Cloud. Agent Registry; Agent Gateway; MCP governance; IAM and semantic governance; agent discovery and runtime-security documentation.

3.4 IBM. watsonx Orchestrate Agentic Control Plane; watsonx.governance; runtime monitoring, agent evaluation, governance, risk, and observability documentation.

3.5 ServiceNow. AI Control Tower; AI asset discovery; agent governance; lifecycle, risk, compliance, identity, and runtime-management documentation.

3.6 Oracle. Fusion AI Agent Studio; agent identity, inherited application security, roles, permission groups, workflows, and enterprise transaction controls.

3.7 SAP. Business AI Platform and Joule; enterprise agents, business context, ERP data, authorization, workflows, integration, and AI governance.

3.8 Salesforce. Agentforce; Einstein Trust Layer; agent identity, permissions, actions, guardrails, data protection, traceability, and lifecycle security.

3.9 OneTrust. AI and agentic governance; privacy, risk, compliance, purpose limitation, organizational policy, data governance, and observability.

3.10 Databricks. Unity Catalog; Unity AI Gateway; MCP governance; governed AI assets; lineage, securable resources, access controls, and policy enforcement.

3.11 NVIDIA. OpenShell and agent-runtime security; sandboxing, process and filesystem isolation, network policy, credential isolation, inference routing, and runtime observability.

3.12 Palo Alto Networks. Prisma AIRS; AI Runtime Security; MCP security; agentic supply-chain security; shadow AI discovery; runtime threat detection and red-team guidance.

3.13 Palantir Technologies. AIP; Ontology; Ontology MCP; governed enterprise objects, action types, permissions, controlled state changes, operational context, and lineage.

3.14 Harness. Agent Development Lifecycle; Worker Agents; AI Evals; AgentTrace; agent-as-code; RBAC and policy governance; sandboxing; evaluation gates; trajectory evaluation; and production-to-test feedback.


How the Research Sources Were Used

The three source classes perform different functions in constructing this architecture.

National standards and government research establish the institutional foundation. They provide direction concerning identity, authorization, least privilege, cybersecurity risk, interoperability, vulnerability information, evaluation, monitoring, and standards development.

Academic and independent research provides the emerging technical frontier. It supplies important concepts concerning harness security, tracked capabilities, Runtime Contracts, dynamic skills, self-evolution, environment interaction, behavioral security, trajectories, tool orchestration, adversarial evaluation, and continuous deployment assurance. Because these ideas can materially shape the architecture, relevant research has been identified where those concepts are discussed.

Enterprise vendor research demonstrates implementation feasibility and reveals architectural convergence. The fourteen vendor environments were examined to identify both recurring best practices and distinctive capabilities that have practical value. Those capabilities were extracted, generalized, and incorporated into the architecture without turning the paper into a product comparison or attributing architectural principles to particular vendors.

The research method can therefore be summarized as:

Standards Define Direction → Research Extends the State of the Art → Enterprise Implementations Demonstrate Practical Mechanisms → Comparative Analysis Extracts Best Practices → Architectural Synthesis Integrates Them → Continuous Research Updates the Architecture.

The resulting Enhanced Agentic Security Architecture is therefore intended neither as a description of one product nor as a static security checklist. It is a researched architectural framework for governing the complete relationship among models, agents, harnesses, capabilities, authority, actions, behavior, consequences, and evidence as enterprise computing becomes increasingly agentic.