All articles

AI

The Agentic Enterprise Needs Credentials and Kill Switches Before Software Starts Acting On Live Data

The Data Wire - News Team

|

August 31, 2026

Peter Corless, Principal Product Marketing Manager at Redpanda, says agents need tightly scoped access and audit trails they can’t alter.

Credit: The Data Wire News

We want to give agents just enough access to do their job, but not too much access, and certainly not to the same degree as the human.

Peter Corless

Principal Product Marketing Manager
Redpanda

Enterprise data pipelines were built to end at a person. Records moved from source systems into a warehouse, a dashboard refreshed, and an analyst decided what to do about the number on screen. Agents now occupy that endpoint, approving payments, rerouting logistics, and querying production systems at machine speed. The access controls and audit practices governing those pipelines assumed a human behind every query, and enterprises connecting agents to live operational data are working through what both should look like when the requester is software.

Peter Corless, Principal Product Marketing Manager at Redpanda, covers AI policy, governance, and regulation for the streaming data company's agentic data plane. He previously served as Director of Product Marketing at StarTree, where his focus was real-time analytics for data-driven enterprises. Today, his work centers on the identity, access, and audit controls enterprises apply to agents running against live systems.

"We want to give agents just enough access to do their job, but not too much access, and certainly not to the same degree as the human," says Corless. Redpanda has been building an internal methodology for managing agents, and Corless starts it at the sizing of permissions. He places that decision alongside credential separation and guardrails among the conditions he considers necessary for security in agentic systems.

The credential problem comes first

Corless measures agent rollout in headcount. A company standing up a thousand agents faces a thousand onboardings, each one requiring its own decisions about what that agent may see and do. "The agents are kind of a new workforce," he explains. "Human resources type policies and procedures aren't going to work for agents. There's a lot of non-predictiveness, the kinds of things you would never expect from an employee you can get out of an agent."

The model he recommends starts with the credential itself. "The agent should be working on behalf of a human," Corless notes. "They're not just running like a service account. They're tied back to some human user who ultimately made the request for this kind of information or data."

Enterprises are treating agent identity as an unsolved problem. The link between an agent and the person who requested the work is what makes narrowing possible, because a credential attached to one person can be measured against one job. Corless puts the choice in terms a data team would recognize, and the answer moves with the task in front of the agent. "This allows you to scope down to the least privileged access what the agent might need to do," he adds. "Does it need read-write privileges to the gold table, or should it have read-only privileges because you're just running an analysis?"

Credential separation also changes what a security team can establish after the fact. Attribution depends on the credential that carried the action, and Corless keeps the two populations apart so that a review can tell them apart without guesswork. "Because of disambiguation, you want to be able to tell what actions the agent took as opposed to a human," he says. "There are nefarious human behaviors that are going on inside of a system, but you want to be able to segregate that from an agent that's just coloring outside the lines."

Setting the proper guardrails

Scoping settles what an agent may reach, and a second set of controls settles what leaves the system in the answer. The same query needs a different response depending on who receives it, because a record that suits one requester can be inappropriate for the next. "A good guardrail system isn't just keeping an agent from doing nefarious activities," Corless explains. "Even with the read only that it has, you also want to make sure that it has masking of that data, like a kind of a redaction, so the data you get back is not untoward data to hand back to a public user. Maybe you need to provide an aggregate rather than individual transactional sums."

Corless locates the weak point in where many deployments keep their own records. An agent running locally writes its transcripts and holds its guardrail configuration on the machine it operates, which gives the process being audited write access to the audit. "A nefarious agent would be able to delete any transcripts so it could clean up any sort of untoward activities it took," he points out. "It could potentially change data, exfiltrate data, and then hide any evidence that it did."

The architecture Corless describes moves policy enforcement and audit logging out of band, into infrastructure that neither the agent nor its operator can write to. The second half of that arrangement concerns permissions on the policy itself. "The humans who may be able to pilot an agent would not necessarily be the people that are putting down the guardrails for those agents," Corless notes. "There could be a higher level of privilege or security of who can change those guardrails."

Kill switches and immutable logs

The same organization runs two requirements that work against each other. Corless describes people who are all gas and no brakes, opening one new tool after another, while the enterprise around them carries conservative requirements and executives with no appetite for becoming a public example. "They're inundated, they're drowning in agents, but they're all being brought in as shadow AI," Corless observes. "If you think about a governor in a car or in an engine, a governor allows things to move as fast as they could without being dangerous. The enterprise needs to set what progress looks like and make sure that we're moving fast but no faster than that."

Guardrails shape behavior while an agent runs, and Corless wants a separate control that ends the run. He argues for a list of operations agreed on in advance, so that spotting one in progress is enough to trigger the stop. "There are certain processes that I might be taking that you need to have corporate kill switches about," says Corless. "It's deleting prod, shut it down."

Immutable logs cover what the guardrails miss, and Corless plans for that gap as a given. Reconstructing an incident depends on a record the agent couldn't have edited while producing it, and Corless treats the handling of that record as a procurement question. "Audit trails are going to be critical, so look for vendors that are committed to these kinds of safety mechanisms and are looking to do this with open standards," he concludes.

Related Stories