AI agents are not ordinary software. An agent holds credentials, calls tools, reads untrusted content, and acts on its own schedule. It composes its next step at runtime instead of following a fixed code path, so your test coverage never proves the full behavior space. Privilege composes too: an agent with read access to a shared drive, write access to an ERP, and outbound email is not three small risks but one large one, because a single run chains them.
In Arlington that lands on a specific kind of organization. Manufacturers and assembly operations run multiple shifts with OT sitting close to IT. Logistics and distribution centers along I-20 and SH-360 ingest outside documents all day. Hospitals, clinics, and the University of Texas at Arlington hold protected health information and student records at scale. The entertainment and hospitality district processes card data at event-day volume. Most of these teams are lean, and few can staff a 24x7 SOC. High-consequence systems plus thin coverage is why agent security has to be designed in, not bolted on. What follows assumes you already have agents in production, approved or not.
Every agent needs its own identity, the narrowest possible tool and data scope, a named human owner, an approval gate on consequential actions, and a logged trail of what it actually did. If you cannot produce those five facts for an agent, it is not ready for production, no matter how well the demo went.
Short answer: you cannot secure what you have not enumerated, and the real count is larger than your ticket queue suggests. Two categories hide well: employees wiring up automations with personal accounts, and vendor-embedded agents that arrived inside SaaS you already pay for. Run discovery across five signals over a two-week window:
Record for each agent: business owner, technical owner, systems touched, data classification reachable, read or write, and whether a human sees output before an action fires. That table is your control plane. Method detail lives in shadow AI discovery and inventory.
Because a borrowed credential destroys attribution, breaks least privilege, and outlives the employee. The pattern we find most often is an agent running as a departed manager's account, or a generic automation login shared across several workflows. When something goes wrong the audit log says a person did it, and nobody can prove otherwise.
For shift-based operations, add a time dimension: a maintenance-scheduling agent on an Arlington plant floor should not be writing to the MES at 3:00 a.m. Sunday if the line is down. Deny by default outside operating windows. More in AI agent identity and access.
Scope the tool, not just the account. An agent granted a generic database tool has your whole database. One granted a parameterized query for open purchase orders at a single plant has exactly that.
Infonaligyget_order_status(order_id), not raw SQL or a full REST surface.Healthcare and higher-education environments should treat minimum necessary access as a design constraint, not a review checkbox: if the agent does not need the identifier, keep it out of context.
Agents should never see raw secrets in prompts, config files, or repository history. Keep credentials in a managed vault, inject them at the tool layer rather than the model layer, rotate on a schedule, and scan prompt logs for credential patterns. If a secret enters a model context, treat it as disclosed and rotate.
Short answer: assume the model can be persuaded, and put the control outside the model. Untrusted text arrives constantly in distribution work: bills of lading, carrier confirmations, supplier invoices, support tickets.
Gate on consequence, not on comfort. Approving everything trains people to click through, which is worse than no gate. Require a human when the action moves money, changes access, touches regulated data, communicates externally under your brand, or affects physical or clinical operations.
Log each approval with reviewer identity, evidence shown, and decision. An approval nobody can reconstruct is not a control.
Capture the run, not just the outcome: agent identity, trigger, tools invoked with parameters, sources read, records changed, approvals requested and granted, cost consumed, and final disposition. Retain to your regulatory requirement and keep it queryable by a person at 2:00 a.m.
Lean teams cannot watch dashboards around the clock, so tune for a handful of high-signal alerts: an agent using a tool it has never used before, volume or cost anomalies against a rolling baseline, access attempts outside approved windows, repeated schema validation failures (often an injection attempt), and any agent-initiated credential or permission change. Route those to on-call staff or a managed detection partner, which is where co-managed security services earn their keep. Instrumentation detail in agent observability and monitoring.
Design the stop before the start, in three layers tested before go-live: pause (halt new runs, let in-flight work finish), revoke (invalidate tokens at the identity provider, killing access mid-run), and roll back (a documented path to reverse writes, so every action is either reversible or flagged irreversible at design time). Name who can pull the switch on every shift, not just business hours, and rehearse quarterly. See containment and kill-switch design.
Same risk, less visibility, because the vendor chose the defaults and some enable agent features without an explicit opt-in. Get written answers per vendor: what data leaves your tenant, whether your content trains any model, which actions run autonomously, what admin controls scope or disable them, what logs you can export, and how injection through customer content is handled. If the vendor cannot answer, that is your answer. See governing vendor-embedded AI agents.
Days 1 to 30, see clearly. Finish the inventory including shadow and vendor-embedded agents. Assign a named owner to each, and retire anything with no owner or no business case. Publish a one-page acceptable use standard so staff know the approved path. Turn on logging wherever it already exists.
Days 31 to 60, control access. Migrate every production agent to its own scoped identity with short-lived credentials. Move secrets into a vault. Narrow tool definitions and retrieval permissions. Stand up approval gates for money, identity, regulated data, and external communication, and define operating windows for shift-bound systems.
Days 61 to 90, prove it holds. Wire alerts to a real on-call path. Run an injection test against every agent that reads external content. Rehearse pause, revoke, and roll back. Add agent identities to the access review. Only then expand autonomy, and only where measured error rates support it.
Infonaligy serves Arlington from our Dallas-Fort Worth base, with engineers on site across Tarrant County and remote delivery nationwide. We design and secure production agents end to end: AI consulting and governance, custom AI agents, process automation, AI DevOps, and hosted AI for controlled environments. For the broader technical baseline, read securing AI agents in 2026, or see the full locations list and the Infonaligy home page.
To review your agent inventory or run an injection test against something already in production, reach us at hello@infonaligy.com or 800-985-1365.
Infonaligy supports IT and security teams in Arlington and across Dallas-Fort Worth on site, with remote delivery for multi-site organizations nationwide.
An Infonaligy engagement starts with a two-week agent discovery across your identity provider, network egress, SaaS admin consoles and service accounts, then delivers scoped workload identities, least-privilege tool definitions, approval gates, monitoring wired to a real on-call path, and a rehearsed containment plan. We work alongside your existing team and stay through the first full review cycle.