Cannot allocate memory error while computing files - Setup Swap space

 

AI Agents Don’t Just Generate Answers. They Operate With Authority.

Recent AI-security advisories took me back to some earlier work i had done with different security products. Integrating Google recaptcha, using Flare.io to identify leaked account credentials, different layers of security and rate limiting at proxy layers and Akamai security on every incoming traffic. There were cases where bots ticked all the check boxes for human. 

The platform could surface signals such as leaked credentials and externally exposed information. But detecting something was rarely the complete problem.

A simple Grafana alert for high traffic, high purchase, spike in logins immediately created more questions:

- Which identity does it belong to?
- What systems can that identity access?
- How quickly can we contain the exposure?

That experience left me with a simple lesson: finding a vulnerability or exposed credential is only the beginning. The real engineering work starts when we try to understand its reach.

That lesson feels even more important today as organizations give AI agents access to source repositories, internal documentation, development tools, cloud services and customer-support systems.

The model is only part of the system

When an AI application produces an incorrect answer, the immediate reaction is often to focus on the model.

- Was the prompt unclear? or Did the model hallucinate? or should different model be used?.

A production AI agent is usually surrounded by a much larger system:

User or external content -> Agent -> Tools, plugins and integrations -> Data, APIs and infrastructure -> 
Real-world side effects

The model may interpret the request, but the surrounding harness determines what the agent can see and what it can do. Recent security guidance has increasingly focused on this broader attack surface. A coding agent, for eg. may load extensions, read repository instructions, call external tools, execute commands and access credentials from its environment. A weakness in any of these boundaries can become more serious when the agent is trusted to act autonomously.

The dangerous part is that the final response may still look completely reasonable. An agent could select the wrong tool, retrieve data it did not need, follow instructions hidden in an external document or attempt an unsafe action—and still return a polished summary saying the task was completed.

AI is accelerating familiar security problems

Many AI-security risks are not entirely new. Organizations have dealt with stolen credentials, excessive permissions, malicious dependencies, insecure plugins and exposed secrets for years. What AI changes is the speed at which these weaknesses can be discovered, connected and acted upon. Consider an exposed developer credential.

On its own, it may provide access to a source repository. That repository may contain configuration details or references to other systems. Those systems may expose additional credentials, cloud resources or customer data.

The path can grow quickly: Exposed credential -> Repository access -> Additional secrets or configuration -> Cloud or production access -> Sensitive-data exposure

A human attacker would have to investigate these steps one by one. An autonomous system may be able to search, correlate and execute several of them much faster and in parallel. That does not mean every AI agent will behave maliciously. It means our security model must account for what could happen if an agent is manipulated, compromised or simply makes the wrong decision with the permissions it has been given.

What working with external-exposure signals taught me

My earlier experience involving multiple security tools eg.Flare.io changed how I think about security monitoring. Externally exposed information does not always appear first in an internal dashboard. Credentials, API keys, session information or company data may surface in repositories, breach collections, stealer logs or other external sources before the affected organization connects them to an internal incident. Flare describes this problem in terms of identifying exposed identities and understanding their possible blast radius across connected services. What stayed with me was that an external signal had limited value without internal context.

Finding a credential did not automatically tell us:

• Whether it was current
• Whether it was still valid
• What permissions it carried
• Where else it had been reused
• Which systems required immediate containment

Detection is useful only when it leads to a decision.

This principle applies directly to AI systems. Logging an agent’s final answer is not enough. We need the context required to determine what happened, what the agent accessed and what consequences followed.

Few questions that should be though when reviewing AI-agent design

1. What untrusted information can enter the agent’s context?

An agent may receive information from users, email, web pages, support tickets, documents, code repositories or another agent. That content is data, but the model can also interpret it as instructions. This creates an unusual trust problem. A document retrieved to answer a question might contain text designed to influence the agent’s next action. A repository could contain malicious instructions intended for a coding assistant. A support request could attempt to persuade an agent to reveal information or call a privileged tool. Input validation therefore cannot stop at checking file types or JSON schemas. We need to understand how retrieved content can affect the agent’s reasoning and tool selection.

My default assumption is simple, external content is untrusted, even when it looks like ordinary business information.

2. What is the maximum authority available to the agent?

This is where many designs become uncomfortable. An agent may only need to read a deployment status, but it receives a token that can modify the deployment. It may need access to one repository, but its credential works across the organization. It may need to draft a customer response, but the integration also allows it to send one. Convenience often wins during a prototype while broad access makes the demonstration easier to build. Those permissions then quietly survive into production. I prefer capabilities that are narrow, temporary and specific to the current task. Short-lived credentials, scoped service identities, explicit tool allowlists and network restrictions are not merely infrastructure details. They define the agent’s real security boundary.

If the agent is compromised, its maximum authority becomes the attacker’s starting point.

3. Can we reconstruct every consequential action?

Traditional application logs often record requests, errors and database operations. An AI-agent trace needs to explain more.

- What information entered the context?
- Which tool did the agent select?
- What parameters did it provide?
- Which authorization decision was made?
- What data was returned?
- What external side effect occurred?

Capturing every internal token is neither necessary nor always desirable. But consequential actions must be explainable. If an agent modifies a record, triggers a workflow, accesses sensitive data or executes code, we should be able to reconstruct the path that led there.

A good final answer does not prove that the execution was safe.

4. Can we contain the system quickly?

This question receives less attention during design reviews than it deserves. Teams need practical containment mechanisms:

• Credential and session revocation
• Per-tool kill switches
• Network isolation
• Rate and spending limits
• Human escalation paths
• Incident-response runbooks
• Recovery validation after containment

Autonomy should be earned

I am optimistic about AI-assisted engineering. I use these tools, experiment with them and see clear opportunities to improve how teams design, build and operate software. But I do not believe autonomy should be granted merely because a demonstration worked. A safer progression looks more like this:

First, the agent recommends - A person reviews and executes the action.

Then, the agent prepares - It constructs the change, but a person approves the consequential step.

Next, it operates within boundaries - The agent performs narrowly defined, reversible actions with explicit limits.

Finally, autonomy expands - This happens only after evaluations, operational evidence and incident controls demonstrate that the system can be trusted within that domain. Not every workflow needs to reach the final stage. For high-impact operations, permanent human approval may be the correct architecture rather than an intermediate limitation.

Secure AI adoption is an architecture problem

Security cannot be added after an agent has already been connected to every system it might need. The important decisions are architectural:

• Where trust boundaries are placed
• How identities and permissions are scoped
• Which actions remain deterministic
• What information the model can access
• How external instructions are separated from internal policy
• What is recorded for investigation
• How quickly authority can be revoked

This requires participation from platform engineering, security, product, data governance and the teams that understand the business process. It is also where senior technical leadership matters.

A Principal or Staff Engineer cannot personally review every prompt or tool call. The larger responsibility is to establish patterns that make the safe path easier for every team:

• Reusable authentication and authorization components
• Standard agent telemetry
• Approved integration patterns
• Evaluation suites for critical workflows
• Default sandboxing and network restrictions
• Clear production-readiness criteria

The objective is not to slow adoption. It is to prevent every team from rediscovering the same security lessons independently.

The fundamentals still matter

AI introduces new behaviour, but many of the strongest protections remain familiar:

- Least privilege.
- Isolation.
- Secure defaults.
- Short-lived credentials.
- Defence in depth.
- Auditability.
- Operational readiness.

What changes is the urgency with which these controls must be applied. An AI agent can combine information and actions in ways that were not explicitly coded in advance. That flexibility is the source of its value - and part of its risk. The goal is not to eliminate autonomy. It is to ensure that autonomy grows only as quickly as our ability to observe, constrain and trust it.