StealthTech
A prime contractor asked us last month whether their new “AI agent” for subcontractor invoice reconciliation needed to touch their System Security Plan. The vendor selling the tool had assured them it was “just automation, like the macros you already use.” It wasn’t. The tool was pulling data from three systems, making judgment calls about discrepancies over a set dollar threshold, and auto-generating vendor communications without a human reviewing the output first. That’s not automation in any sense a compliance auditor would recognize. That’s an agent, and it changes the risk conversation entirely.
This distinction matters more in the defense industrial base than almost anywhere else, because the difference between automation and agentic AI isn’t academic here — it determines what touches Controlled Unclassified Information, what needs to be documented in your SSP, and what a DCMA assessor is going to ask about when they show up. Most of the marketing language floating around right now blurs the line on purpose. Vendors want you to believe agentic AI is just automation’s more capable cousin. It isn’t, and treating it that way is how contractors end up with compliance gaps they didn’t know they had.
What Traditional Automation Actually Does
Traditional automation — the kind most contractors have been running for years through RPA platforms, Power Automate flows, or scripted integrations — operates on fixed logic. If a condition is met, a predetermined action fires. There’s no interpretation happening. A rule says “if invoice total exceeds $10,000, route to manager for approval,” and the system does exactly that, every time, in exactly the same way, regardless of context.
This predictability is the entire value proposition. You can document the logic once, test it, and know with certainty what it will do next month or next year unless someone changes the code. For compliance purposes, that’s a gift. An auditor can trace the rule, confirm it matches the documented control, and move on. Traditional automation doesn’t make decisions; it executes decisions someone already made and encoded.
The limitation is equally obvious: automation can’t handle anything it wasn’t explicitly told to handle. A slightly malformed invoice, an email that doesn’t match the expected template, a vendor name spelled two different ways across systems — these break brittle automation constantly, which is why so many contractors still have people manually cleaning up exceptions that “automated” workflows kick out. Most organizations running managed IT services already have dozens of these rule-based flows quietly doing useful, boring work in the background, and there’s nothing wrong with that. The mistake is assuming the next generation of tools works the same way, just faster.
What Makes an Agent an Agent
Agentic AI systems don’t follow a fixed script. They’re given a goal, access to tools or data sources, and the latitude to figure out the steps to get there — including steps nobody explicitly programmed. An agent tasked with “resolve this vendor invoice discrepancy” might query three different systems, decide which one is authoritative, draft a response, and send it, all without a human touching any of those individual steps. It’s reasoning, in a limited but real sense, and that reasoning is probabilistic rather than deterministic.
This is the part that should give a compliance officer pause. Run the same input through an agent twice and you may not get the same output twice. That’s not a bug to be patched; it’s the nature of how large language models generate responses. For a marketing team drafting blog outlines, that variability is a minor inconvenience. For a contractor whose System Security Plan describes exactly how CUI moves through a process, unpredictable agent behavior is a control that can’t be adequately documented, which means it’s a control an assessor will flag.
None of this means agentic AI is unusable in a regulated environment. It means the adoption conversation has to start with governance, not capability. Anyone evaluating AI integration for a business handling federal contract data needs to know upfront which category of tool they’re actually buying, because the sales pitch rarely draws this line for you.
The CUI Problem Nobody’s Vendor Wants to Talk About
Here’s where it gets specific to this industry. Under 32 CFR Part 2002 and the CUI registry maintained by the National Archives, Controlled Unclassified Information has to be safeguarded according to defined categories and marking requirements, regardless of what system is processing it. An AI agent that ingests a technical drawing, a bill of materials, or a proposal draft containing CUI in order to “help” with a task is now a system that touches CUI — and if that agent is a SaaS product running on infrastructure you don’t control, you have a boundary problem your SSP needs to account for.
Traditional automation rarely creates this issue because it typically moves data between systems you already govern, following logic you already documented. Agentic AI tools frequently call out to external APIs, third-party model providers, or cloud services that weren’t part of your original compliance boundary. If that agent is summarizing a document that includes CUI and sending the summary to an external LLM API for processing, you may have just created a data flow that falls outside your authorized boundary under NIST SP 800-171 Rev. 3, and outside what DFARS 252.204-7012 requires you to safeguard.
This is precisely the scenario our team was called in for with the Sarasota contractor referenced in our recent AI readiness assessment guide — an engineering team feeding drawing revisions into a consumer AI tool because it made their job faster, with nobody stopping to ask where that data actually went. The tool wasn’t malicious. It was agentic automation doing exactly what it was designed to do, just without anyone checking whether the design matched the compliance boundary.
Data Governance Has to Come Before the Pilot, Not After
The instinct with any new productivity tool is to run a small pilot, see if it works, and scale from there. With agentic AI in a CUI environment, that sequence is backwards. You need to answer the data governance questions before a single document touches the tool, because once CUI has left your boundary, you can’t un-ring that bell.
The questions worth asking before a pilot starts: Where does the agent’s underlying model run, and is that infrastructure within your authorization boundary? Does the vendor retain your data for model training, and can you contractually prohibit that? What logging exists to reconstruct exactly what the agent accessed and what it did with it, since NIST SP 800-171A auditors will ask for evidence, not assurances? And critically — does the agent have write access to systems, or is it limited to read-and-recommend, with a human approving any action that touches CUI or a production system?
Contractors who skip this step tend to discover the answers during an assessment rather than before deployment, which is the expensive way to learn them. Our compliance team walks through exactly this kind of boundary mapping before any AI tool gets greenlit for a client handling federal contract data, because the SSP has to reflect reality, not the vendor’s marketing copy.
Where the Cost and ROI Math Actually Plays Out
Vendors selling agentic AI tools love to lead with headcount savings, and sometimes those numbers are real. But the total cost of ownership calculation looks different once you factor in the governance overhead that a regulated environment requires, and it’s worth being honest about where each approach tends to pay off and where it tends to quietly drain budget instead.
Traditional automation still wins on pure cost predictability. Once built, a rules-based workflow requires minimal ongoing maintenance beyond periodic review, and its behavior doesn’t change without someone changing the code — which makes it cheap to audit and cheap to insure against surprises. Agentic AI can deliver bigger productivity gains on complex, judgment-heavy tasks, but those gains come with recurring costs that are easy to underestimate:
- Ongoing monitoring and logging infrastructure to satisfy audit requirements, which traditional automation rarely needs at the same depth
- Human-in-the-loop review processes for any agent action touching CUI, which offsets some of the labor savings the tool was supposed to deliver
- Vendor risk management overhead, since every agentic tool touching your environment needs its own security assessment and contractual data handling terms
- Model drift and retraining considerations that don’t exist in static rule sets, requiring periodic revalidation that the agent still behaves as expected
None of this means agentic AI doesn’t pencil out. It means the business case has to include compliance labor as a real line item, not an afterthought. A contractor evaluating cloud transformation alongside an AI rollout should be running both cost models side by side before committing budget, and our vCIO services team builds exactly that comparison for clients trying to separate genuine ROI from vendor optimism — a distinction we cover in more depth in our breakdown of what a vCIO actually does for a defense contractor.
What Goes Wrong When Nobody’s Watching the Agent
The failure modes for agentic AI don’t look like the failure modes contractors are used to from automation. A broken automation script usually fails loudly — a task doesn’t run, an error log fills up, someone notices within a day. An agent that’s quietly making bad judgment calls can fail silently for weeks, because it’s still producing output, just output that’s subtly wrong.
We’ve seen agents summarize technical documents in ways that dropped critical qualifiers, draft vendor communications with confident-sounding but incorrect claims about contract terms, and pull data from a stale system record because it had no way of knowing a more current source existed. None of these looked like failures to the humans glancing at the output. They looked like the tool working as intended, right up until someone downstream acted on bad information.
This is also where security exposure compounds. An agent with broad tool access and API permissions is a bigger attack surface than a narrow, rules-based script, and CISA has been explicit that AI systems introduce novel classes of vulnerability that traditional cybersecurity tooling wasn’t built to catch. Prompt injection — where malicious instructions embedded in a document or email trick an agent into taking unauthorized action — has no real analog in traditional automation, because traditional automation doesn’t interpret natural language instructions as commands. If your agent reads email, reads uploaded documents, or reads web content as part of its workflow, that’s now a channel an attacker can potentially use to manipulate its behavior, and it belongs in your threat model the same way phishing does. Reviewing the NIST National Vulnerability Database for AI-adjacent CVEs is becoming as routine a practice as patch management used to be for traditional software.
A Practical Framework for Evaluating Agentic AI Before You Buy
Given all of that, the decision framework for a contractor considering agentic AI doesn’t need to be complicated, but it does need to be deliberate. Before signing anything, we walk clients through a short set of gating questions that determine whether a tool is even a candidate for a regulated environment:
- Does the tool touch CUI or FCI at any point in its workflow, and if so, does its infrastructure fall inside your authorized boundary?
- Can the vendor provide detailed logging sufficient to reconstruct every action the agent took, on demand, for an assessor?
- Is there a mandatory human checkpoint before the agent takes any action that’s irreversible or touches a production system?
- Does the vendor’s data retention and training policy meet the same bar you’d require of any subcontractor handling covered defense information?
- Has the tool, or a comparable one, appeared in guidance from CISA, NIST, or the DoD CMMC Program regarding acceptable use in a CUI environment?
A tool that fails the first two questions probably isn’t ready for anything touching your compliance boundary, no matter how good the demo looked. This is the same rigor we’d apply evaluating any new vendor relationship, and it’s covered in more depth in our piece on measuring cybersecurity maturity without relying purely on compliance checklists — maturity means knowing which questions to ask before the auditor does.
Boston, Tampa, and Sarasota: Why Your Supply Chain Tier Changes the Calculus
The right answer here isn’t uniform across every defense contractor, and geography plus contract tier matters more than most vendors acknowge. A Tier 1 prime in the Boston advanced manufacturing corridor handling higher-sensitivity CUI under a DoDI 5230.24 controlled technical information designation has far less margin for agentic experimentation than a Tier 3 subcontractor in Tampa doing back-office automation with no CUI exposure at all. We see this play out constantly across our Boston, Tampa, and Sarasota client base — the same AI tool that’s a reasonable pilot for one client is a nonstarter for another, purely based on what data actually flows through their environment and where they sit in the prime-subcontractor chain.
This is also where the co-managed model earns its keep. Contractors with a lean internal IT function often don’t have the bandwidth to run a proper AI vendor assessment on top of everything else on their plate, which is exactly the gap our co-managed IT engagements are built to fill — we’re not replacing an internal team, we’re giving them the compliance and security depth to evaluate these tools correctly, a distinction we lay out in detail in our comparison of co-managed versus fully outsourced IT models. Manufacturing and engineering firms in particular are fielding aggressive AI sales pitches right now, and having a partner who understands both the manufacturing floor and the engineering design workflow, alongside the compliance requirements layered on top, changes how quickly a contractor can say yes to the tools that are actually safe and no to the ones that aren’t.
Budget is part of this conversation too, and it’s worth grounding expectations against real numbers rather than vendor projections — our recent breakdown of what managed IT actually costs a small business in 2026 is a useful reference point for contractors trying to figure out where AI governance spend should sit relative to their broader IT budget, and it pairs well with the metrics guidance in our piece on cybersecurity KPIs CEOs should actually be tracking when reporting AI-related risk up to leadership.
Conclusion
Traditional automation and agentic AI aren’t competing products on the same shelf — they’re fundamentally different risk categories wearing similar marketing language, and defense contractors don’t have the luxury of treating them interchangeably. Automation gives you predictability you can document and defend in an assessment. Agentic AI can deliver real productivity gains on harder problems, but only if the governance work — boundary mapping, logging, human checkpoints, vendor vetting — happens before deployment, not after a CUI exposure forces the conversation. The contractors getting this right aren’t the ones moving fastest; they’re the ones asking the CUI and CMMC Program boundary questions before the pilot starts, not during the next assessment cycle.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
