MICHAEL ALLEN HART

AI Security Architect | AI Security Consultant

Protecting AI. Protecting What’s Next.

Michael Allen Hart / AI Security Consultant

Enterprise AI Security Architecture | Multi-Agent Systems | AI Assurance

01 / INTRODUCTION

Experienced AI Security Architect specialising in multi-agent systems, enterprise AI security and the design of secure, resilient AI architectures.


Expertise spanning four critical security domains: Agentic AI, LLM and Model Security, RAG and Data Security, and Infrastructure Security.


Particular specialisation in multi-agent security architecture, with a focus on protecting autonomous systems, enforcing trust boundaries and securing interactions between agents, tools and enterprise infrastructure.

Experienced AI Security Architect specialising in multi-agent systems, enterprise AI security and the design of secure, resilient AI architectures.


Expertise spanning four critical security domains: Agentic AI, LLM and Model Security, RAG and Data Security, and Infrastructure Security.


Particular specialisation in multi-agent security architecture, with a focus on protecting autonomous systems, enforcing trust boundaries and securing interactions between agents, tools and enterprise infrastructure.

PROFESSIONAL PROFILE & CV

Experience Behind the Architecture.

Senior AI Security Architect with 15+ years of experience across financial services, UK Government, defence, energy and critical national infrastructure. Specialising in enterprise AI security architecture, agentic AI, multi-agent systems, model and RAG security, and independent assurance.

CURRICULUM VITAE

Michael Allen Hart

Public CV · PDF document

View or Download My CV

View CV

Download CV

View the PDF in a new tab or download a copy.

05 / CONTACT

Let’s Discuss Your AI Security Challenges.

Whether you’re recruiting for an AI security architecture role, exploring an enterprise AI initiative, or looking for specialist architecture and assurance expertise, please get in touch.

Enterprise AI Security Reference Architecture — Conceptual Design Demonstrating Operational Security Controls and Independent Assurance.

Your details will only be used to respond to your enquiry. Please do not include confidential or sensitive information.

Form delivery is awaiting configuration. You can also email MichaelAllenHart@icloud.com.

02 / ARCHITECTURE LAB

Four Security Lenses. One Unified AI Architecture.

Explore AI security through four interconnected lenses: Agentic AI, LLM and Model Security, RAG and Data Security, and Infrastructure Security. Discover how each perspective contributes to a unified enterprise security architecture.

Selected lens D5: Unified Architecture
Michael Allen Hart — AI Security ConsultantSolid arrows show runtime control and data flow between identity, orchestration, model gateway, governed RAG, tools, business authorisation, and protected systems. Dashed arrows show independent assurance evidence paths only, ending at the assurance band.Enterprise Users & IdentityIdentity proofing• SSO• policy context claimsAgent Orchestration & DelegationTask planning• delegated steps• local tool policy onlyModel Gateway & LLMsModel routing• provider trust boundary• safety filtersGoverned RAG & Enterprise DataUser enterprise data access• data provenance• grounding evidenceTools, APIs & Platform SecurityTool/API authorisation• workloads• credentials• network egressBusiness Authorisation & SecurityEnforcementG3 · Backend business effects• Originating-user entitlements• Separation of dutiesProtected Enterprise Systems &EgressProtected business systems• Disclosure enforced separatelyEgress enforcementSensitive disclosuregate at outbound boundaryIndependent Assurance & Release GovernanceIndependent verification scope• dashed evidence lines• G2 release eligibility only
Local tool policy is not originating-user business authorisation. Business authorisation and protected business effects are enforced at the backend G3 boundary; sensitive disclosure remains separately egress-enforced.
Independent assurance verifies evidence and outcomes; it does not authorise individual transactions. G2 release eligibility only.
Conceptual public presentation groups of V5.8 only; not deployed or production-tested claims.

03 / SELECTED WORK

Architecture in practice.

04 / EXPERIENCE

Experience. Expertise. Perspective.

AI Security Experiments

Practical experimentation has shaped my approach to enterprise AI security. Selected work includes:


  • Multi-Agent Payment Authorisation: Tested three scripted agents whose individual workflow steps were permitted. A separate authority check rejected the prohibited payment while the legitimate payment committed once.

  • AWS Authority Revocation: Tested two execution services holding different authority versions. A locally permitted action was rejected by the protected backend after authoritative permissions changed.

  • AWS & Docker Security Validation: Conducted controlled experiments covering delegated permissions, child-agent authority, shared workflow budgets, revocation and backend authorisation.

  • Independent Outcome Verification: Inspected actual backend records rather than relying on agent-reported success. Identified and corrected a verifier-access defect, then retested.

  • Executable AI Security Prototype: Developed an AI-assisted Python prototype exploring OpenFGA relationship checks, policy enforcement points, bounded delegation and authority-path analysis. Historical local tests recorded 430 functional checks and 17 mocked contract checks.

  • Enterprise PaaS Integration Assessment: Performed live, non-destructive, read-only security checks through an AI-connected interface. Identified a potential least-privilege concern associated with an administrator-profile integration identity, requiring further assessment.

What the Experiments Revealed

The most valuable lessons came from examining what security controls actually enforced—and what they did not.


  • Permitted Actions Can Produce Prohibited Outcomes: Individually permitted agent steps do not automatically authorise their combined business effect. Final business-effect authorisation matters.

  • Local Permissions Can Become Stale: The AWS revocation experiment demonstrated why current backend authority must take precedence over locally held permission state.

  • Tool Success Is Not Transaction Success: Agent or API responses alone cannot establish whether a protected transaction actually committed. Independent backend verification is essential.

  • Assurance Mechanisms Need Testing Too: A verifier-access defect demonstrated that the systems used to validate security outcomes can themselves fail and require correction.

  • Integration Identity Is a Critical Trust Boundary: PaaS and SaaS connectors inherit the privileges of their execution identities. Excessive privileges can undermine otherwise well-designed security boundaries.

  • Experimental Success Is Not Production Assurance: Controlled tests demonstrated selected security behaviours. Wider bypass paths, outage conditions and some environment-cleanup issues remained unresolved.

FEATURED ARTICLE / TECHNICAL PERSPECTIVE

What Would Happen if Malware created 100 Hostile AI Agents Taking Control of Your Enterprise?

Explore the emerging security challenges of autonomous AI systems, multi-agent threats and the enterprise security architecture needed to defend against them.

Read the Article →

(2) Malware Enters an Enterprise Network. 1,000 Hostile AI Agents Are Born. What Would Prevent This? | LinkedIn