Coding agent telemetry: எவற்றையெல்லாம் கண்காணிக்கிறது?

Coding agent telemetry எவற்றையெல்லாம் உள்ளடக்குகிறது

Coding agent telemetry என்பது ஒரே சொல்லால் அழைக்கப்பட்டாலும், நான்கு தனித்தனி தரவுப் பரிமாற்றங்களைக் கொண்டது. ஒவ்வொரு பரிமாற்றத்திற்கும் தனித்தனி கட்டுப்பாடுகள் உள்ளன. Model inference உங்கள் prompts மற்றும் code-ஐ model-ஐ வழங்கும் நிறுவனத்திற்கு அனுப்புகிறது; இதைத் தடுக்கும் வசதி எந்த அமைப்பிலும் இல்லை. Product analytics மற்றும் crash reports ஆகியவை vendor-க்கும், பெரும்பாலும் அவர்கள் பணம் செலுத்தும் logging நிறுவனத்திற்கும் செல்கின்றன. பயிற்சியிற்காகத் தரவுகளைத் தக்கவைத்தல் (Retention) என்பது network சார்ந்ததல்ல, அது ஒரு ஒப்பந்தம் சார்ந்த விஷயம். நான்காவது பரிமாற்றம் பலரால் கவனிக்கப்படுவதில்லை: நீங்கள் சேர்க்கும் ஒவ்வொரு integration-ம், நீங்கள் தேர்வு செய்யாத ஒரு host-க்கு இணைப்பை ஏற்படுத்தக்கூடும்.

தற்போதைய vendor defaults குறித்த பட்டியல், இந்தத் துறையில் மிக விரைவாகப் பழையதாகிவிடும். ஒரு புதிய release இயல்புநிலையை மாற்றலாம்; ஒரு புதிய feature, எந்த switch-உம் கட்டுப்படுத்தாத ஒரு புதிய destination-க்குத் தரவை அனுப்பலாம். எனவே, எந்தவொரு agent-க்கும் நீங்கள் மீண்டும் மீண்டும் செய்யக்கூடிய ஒரு தணிக்கை (audit) முறையை அறிந்துகொள்வதே நிரந்தரமான திறன் ஆகும்: vendor வழங்கும் ஆவணங்களைப் படியுங்கள், இந்த machine-ல் எந்த config உண்மையில் அமலில் உள்ளது என்பதைச் சரிபார்க்குங்கள், machine-லிருந்தே அந்த process-ஐக் கண்காணியுங்கள், பிறகு உங்களுக்கு உகந்த கட்டுப்பாடுகளைத் தேர்வு செய்யுங்கள். கீழே உள்ள ஒவ்வொரு command-ம் உங்கள் சொந்த machine-ல், உங்கள் சொந்த network traffic-ஐக் கண்காணிக்க நீங்கள் இயக்கக்கூடியவை.

நான்கு வகைகள் மற்றும் அவற்றுக்கு ஏன் வெவ்வேறு கட்டுப்பாடுகள் தேவை

Model inference traffic தவிர்க்க முடியாதது. நீங்கள் கொடுத்த prompt, அது வாசித்த கோப்புகள், அது இயக்கிய கட்டளைகளின் வெளியீடு மற்றும் அது உருவாக்கிய உரை ஆகியவற்றை agent ஒரு model endpoint-க்கு அனுப்புகிறது. இதுவே அந்த product-ன் செயல்பாடாகும். யாரிடம் அந்தத் தரவு செல்கிறது என்பது மட்டுமே நீங்கள் எடுக்கும் முடிவு: மற்றவர் நடத்தும் API அல்லது நீங்கள் சொந்தமாக இயக்கும் model. ஒரு நிறுவனத்தின் cloud account (Bedrock, Vertex, Foundry) பெறுநரை மாற்றுகிறதே தவிர, தரவுப் பரிமாற்றத்தை நிறுத்துவதில்லை. இந்தத் தொகுப்பின் பிற பகுதிகள் எவையும் inference traffic-ஐக் குறைப்பதில்லை, எனவே மற்ற மூன்றிலிருந்து இதைத் தனித்தனியாகக் கருத்தில் கொள்ளுங்கள்.

Product analytics மற்றும் crash reporting ஆகியவை வெவ்வேறு host-களுக்குச் செல்லும் தனித்தனி ஓட்டங்கள். Usage counters, latency எண்கள், feature-flag தேடல்கள் மற்றும் stack traces ஆகியவை பொதுவாக model API-க்குத் தொடர்பில்லாத hostnames-க்குச் செல்லும், பெரும்பாலும் மூன்றாம் தரப்பு error tracker-க்குச் செல்லும். விற்பனையாளர்கள் இவற்றை "metrics" மற்றும் "error reports" என்று ஆவணப்படுத்துவார்கள், மேலும் ஒவ்வொரு வகைக்கும் ஒரு environment variable-ஐ வழங்குவார்கள். இதன் அளவு மிகச் சிறியது, எனவே byte எண்ணிக்கையை வைத்து இதைக் கண்டறிய முடியாது. நீங்கள் bandwidth-ஐ அல்ல, hostnames-ஐத் தேட வேண்டும்.

Retention மற்றும் training ஆகியவை கொள்கை சார்ந்தவை, packet சார்ந்தவை அல்ல. விற்பனையாளர் உங்கள் prompt-களைச் சேமிக்கிறாரா, எவ்வளவு காலம் வைத்திருக்கிறார், எதிர்கால model-ஐப் பயிற்றுவிக்க அவற்றைப் பயன்படுத்துகிறாரா என்பது உங்கள் திட்டத்துடன் இணைக்கப்பட்ட விதிமுறைகளில் எழுதப்பட்டிருக்கும். Consumer திட்டங்களும் வணிகத் திட்டங்களும் பொதுவாக மாறுபடும், மேலும் zero-retention ஒப்பந்தம் என்பது வழக்கமாகத் தனிப்பட்ட ஒப்பந்தமாகும். tcpdump மூலம் இதை உங்களால் சரிபார்க்க முடியாது, ஏனெனில் packet-ன் வடிவம் இரண்டு நிலைகளிலும் ஒரே மாதிரியாகவே இருக்கும். விதிமுறைகளை வாசியுங்கள், உங்கள் நிறுவனத்திற்கு அது முக்கியமென்றால், அதை எழுத்துப்பூர்வமாகப் பெறுங்கள்.

Integrations அமைதியாக ஒரு கூடுதல் hop-ஐச் சேர்க்கின்றன. ஒரு MCP (model context protocol) server, plugin marketplace, auto-update சோதனை, web search tool, ஒரு URL-ஐப் பெறுவதற்கு முன் அதைச் சரிபார்க்கும் பாதுகாப்புச் சோதனை என ஒவ்வொன்றும் model endpoint அல்லாத ஒரு host-க்குச் செல்லும் கோரிக்கையாகும். இங்குதான் ஆச்சரியங்கள் காத்திருக்கின்றன, ஏனெனில் நீங்கள் local என்று நினைத்த வேலையை ஒரு harness அதன் சொந்த service வழியாக அனுப்பலாம், மேலும் உங்கள் config-ல் ஒரு வரியைக் கூட மாற்றாமல் ஒரு release இதைத் தொடங்கலாம். நீங்கள் சேர்க்கும் ஒவ்வொரு கருவியையும், network-ல் அதைக் கண்காணிக்கும் வரை, ஒரு புதிய இலக்காகவே கருதுங்கள்.

படி 1: விற்பனையாளரின் ஆவணங்கள் என்ன கூறுகின்றன?

உங்கள் agent-க்கான settings reference மற்றும் data usage பக்கங்களைத் திறந்து, பின்வரும் சொற்களைக் கொண்ட பட்டியலுடன் அவற்றை வாசிக்கவும்: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. இதில் ஒவ்வொரு சொல்லும் பொதுவாக ஒரு தனித்தனி switch-ஆக இருக்கும். அந்த variable பெயர்களைக் குறித்துக் கொள்ளுங்கள், ஏனெனில் படி 2-ல் அவற்றை grep செய்ய வேண்டியிருக்கும்.

ஒரு சொல் உங்களை தவறாக வழிநடத்தலாம். பல agents-ல், ஆவணங்களில் உள்ள "telemetry" என்பது OpenTelemetry export-ஐக் குறிக்கும். இது நீங்கள் இயக்கும் collector-க்கு metrics-ஐ அனுப்ப நீங்கள் configure செய்வது; இது தரவு விற்பனையாளருக்குச் செல்வதற்கு நேர்மாறானது. Claude Code இத்தகையது: CLAUDE_CODE_ENABLE_TELEMETRY=1-ஐ அமைப்பது OTEL_EXPORTER_OTLP_ENDPOINT-ல் நீங்கள் குறிப்பிடும் endpoint-க்கு export-ஐத் தொடங்கும். இது விற்பனையாளரின் சொந்த analytics-உடன் தொடர்புடையது அல்ல, அதற்குத் தனி opt-out உள்ளது. எதையும் அமைக்கும் முன் தரவு எந்தத் திசையில் பாய்கிறது என்பதைத் தீர்மானிக்கவும்.

ஒரு master switch இருக்கும் என்று எதிர்பார்க்கலாம், அதில் ஓட்டைகளும் இருக்கலாம். ஆகஸ்ட் 2026 நிலவரப்படி, Claude Code-ன் CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC என்பது metrics, error reports, feedback command மற்றும் session surveys ஆகியவற்றை ஒன்றாக முடக்குகிறது. அதே ஆவணத்தின்படி, இது WebFetch domain safety check-ஐ உள்ளடக்குவதில்லை. இது நீங்கள் fetch செய்யப்போகும் hostname-ஐ விற்பனையாளர் API-க்கு அனுப்பும், இதற்குத் தனி அமைப்புகள் உள்ளன. இது ஒரு குறிப்பிட்ட தயாரிப்பைப் பற்றிய புகாரல்ல. இது எல்லா இடங்களிலும் உள்ள சிக்கலின் வடிவம்: ஒரு master switch என்பது அது உருவாக்கப்பட்டபோது இருந்த வகைகளை மட்டுமே உள்ளடக்கும்.

opt-out செய்வதால் உங்களுக்கு இழப்பு ஏற்படலாம் என்பதையும் எதிர்பார்க்கவும். telemetry-ஐ முடக்குவது, சில அம்சங்கள் சார்ந்திருக்கும் feature-flag evaluation-ஐயும் முடக்கும் என்று அதே ஆவணங்கள் குறிப்பிடுகின்றன. எனவே, தனியுரிமைக்காக (privacy) மாற்றப்படும் ஒரு switch, நீங்கள் பயன்படுத்தும் ஒரு அம்சத்தை முடக்கலாம்; இவை இரண்டையும் இணைக்கும் எந்த error message-ம் இருக்காது. flag-ன் பெயரை மட்டும் பார்க்காமல், அதற்கு அடுத்த வரியையும் வாசிக்கவும்.

படி 2: எந்த configuration உண்மையில் அமல்படுத்தப்பட்டது?

நீங்கள் எழுதிய ஒரு setting, அமல்படுத்தப்பட்ட setting-ஆக இருக்க வேண்டிய அவசியமில்லை. Agents பல கோப்புகளிலிருந்து configuration-ஐ ஒன்றிணைக்கின்றன. அவற்றில் ஒன்று, நீங்கள் வேறொருவரிடமிருந்து clone செய்த repository-க்குள் இருக்கலாம். உங்கள் shell-ன் environment-லிருந்து தொடங்கவும்.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

பின்னர், ஆவணங்கள் குறிப்பிடும் வரிசையில், அந்த tool வாசிக்கும் ஒவ்வொரு settings கோப்பையும் அச்சிடவும். Claude Code-ஐப் பொறுத்தவரை, ஆகஸ்ட் 2026 நிலவரப்படி, அது user கோப்பு, இரண்டு project கோப்புகள் மற்றும் Linux-ல் உள்ள ஒரு managed policy directory ஆகும்.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

git clone உடன் வந்த ஒரு project கோப்பு என்பது அந்நியர் ஒருவர் எழுதிய configuration ஆகும். உங்கள் user கோப்பு எதை முடக்கியதோ, அதை இது மீண்டும் செயல்படுத்தக்கூடும். எந்தெந்த sources ஏற்றப்பட்டன என்பதைப் பட்டியலிடும் status command அந்த agent-க்கு இருந்தால், அதுவே மிக விரைவான உண்மை நிலையைத் தரும்: Claude Code ஏற்றப்பட்ட settings sources-ஐ /status-ல் அச்சிடுகிறது.

எந்தவொரு கோப்பையும் விட, இயங்கும் process-ஐ வாசிப்பதே மிக வலுவான சரிபார்ப்பு முறையாகும். முதலில் அந்த agent-க்கு எனத் தனி Linux user account-ஐ உருவாக்கவும்; இது இந்த post-ல் உள்ள ஒவ்வொரு command-ஐயும் சுருக்கமாக்கும். பின்னர், அந்த process எந்த environment-ல் தொடங்கப்பட்டதோ அதை வாசிக்கவும்.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ என்பது exec நேரத்தில் அந்த process கொண்டிருந்த variables-ஐக் காட்டுகிறது. எனவே, உங்கள் .bashrc export, systemd மூலம் தொடங்கப்பட்ட service-க்குச் சென்றடையாத சூழலை இது கண்டறியும். நீங்கள் set செய்த variable இதில் இல்லை என்றால், உங்கள் dotfiles என்ன சொன்னாலும், அது செயல்பாட்டில் இல்லை என்று அர்த்தம்.

படி 3: இது எந்தெந்த hosts-உடன் இணைகிறது?

ஏஜென்ட் இயங்கும் கணக்கின் (account) அடிப்படையில் வடிகட்டப்பட்ட, திறந்த நிலையில் உள்ள sockets-உடன் தொடங்கவும்.

sudo ss -tnpe state established

-e ஒவ்வொரு வரியிலும் ஒரு uid: புலத்தைச் சேர்க்கிறது. இதனால், process பெயர்களைப் படிக்காமலேயே, உங்கள் browser-ன் இணைப்புகளிலிருந்து ஏஜென்ட்டின் இணைப்புகளைப் பிரிக்க முடியும். தொலைதூர முகவரிகளைக் (remote addresses) குறித்துக் கொண்டு, அவற்றின் பின்னால் உள்ள பெயர்களைக் கண்டறியவும். பெயர்களைக் கண்டறிய மிகத் தெளிவான வழி TLS (transport layer security) handshake ஆகும். ஏனெனில், ஒவ்வொரு புதிய இணைப்பும் ClientHello-வுடன் தொடங்குகிறது. இதில் SNI (server name indication) புலம் இருக்கும், இது client கோரிய hostname ஆகும்.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

ஒவ்வொரு புதிய இணைப்பிற்கும் ஒரு வரி கிடைக்கும், இதுவே உங்களுக்குத் தேவையான பட்டியல்: model API, update server, analytics host, error tracker மற்றும் integration மூலம் சேர்க்கப்பட்ட பிற சேவைகள். பெயர் நெடுவரிசை காலியாக இருந்தால், அந்த client ECH (encrypted client hello)-ஐப் பயன்படுத்தியுள்ளது என்று அர்த்தம். எனவே, hostname-ஐ நெட்வொர்க்கில் பார்க்க முடியாது. அத்தகைய சூழலில், destination IP முகவரி, reverse lookup அல்லது படி 4-ல் உள்ள proxy-ஐப் பயன்படுத்த வேண்டும்.

DNS (domain name system) பார்வை ஒரு பயனுள்ள குறுக்கு-சரிபார்ப்பு (cross-check) ஆகும். ஏனெனில், ஏஜென்ட் முழுமையடையாத இணைப்புகளுக்குக் கூட எந்தெந்த பெயர்களைத் தேடியது என்பதை இது காட்டும்.

sudo tcpdump -ni any -l 'udp port 53'

ஒவ்வொரு query வரியும் record வகை மற்றும் பெயருடன் A? host.example.net. (39) என்ற வடிவத்தில் முடிவடையும். வெளிப்புற interface-க்கு பதிலாக any-ல் capture செய்யவும். ஏனெனில், systemd-resolved மூலம் application ஆனது 127.0.0.53-ல் உள்ள ஒரு local stub listener-உடன் பேசுகிறது, அந்த stub மட்டுமே வெளியுலகத்துடன் தொடர்பு கொள்கிறது. ஏஜென்ட் சரியாகச் செயல்படும்போது கூட DNS traffic எதையும் நீங்கள் பார்க்கவில்லை என்றால், அந்த runtime தானாகவே DNS over HTTPS-ஐப் பயன்படுத்துகிறது என்று அர்த்தம். அத்தகைய சூழலில், படி 4 மட்டுமே உங்களுக்குப் பெயர்களைத் தரும்.

ஏஜென்ட் உண்மையான வேலைகளைச் செய்யும்போது capture செய்யவும். ஒரு session-ஐத் தொடங்கவும், ஒரு கோப்பைப் படிக்கச் சொல்லவும், ஒரு கட்டளையை இயக்கச் சொல்லவும், ஏதேனும் ஒன்றில் தோல்வியடையச் செய்யவும். தொடக்கத்தில் மட்டும் நிகழும் அல்லது பிழை ஏற்படும்போது மட்டும் நிகழும் traffic, சும்மா இருக்கும்போது (idle) எடுக்கப்படும் capture-ல் தெரியாது. ஒரு தணிக்கையின்போது தவறான முடிவுக்கு வர, idle capture-ல் எடுப்பதே பொதுவான காரணமாகும்.

படி 4: கோரிக்கைகளுக்குள் (requests) என்ன இருக்கிறது?

Hostnames மூலம் யார் என்பதை அறியலாம். என்ன நடக்கிறது என்பதைப் பார்க்க, agent-க்கு முன்னால் நீங்கள் கட்டுப்படுத்தும் ஒரு proxy-ஐ வைத்து, அந்த runtime-க்கு மட்டும் அதன் certificate authority (CA)-ஐ நம்புங்கள். இதற்கு mitmproxy ஒரு பொதுவான கருவியாகும். இந்தத் திட்டம் mitmproxy.org தளத்திலிருந்து standalone binaries-ஐப் பயன்படுத்தப் பரிந்துரைக்கிறது, மேலும் uv tool install mitmproxy-ஐ Python package வழியாகப் பயன்படுத்த ஆவணப்படுத்துகிறது.

mitmdump -w /tmp/agent-flows.mitm

முதல்முறை இயக்கும்போது, ஒரு CA ~/.mitmproxy/-ல் எழுதப்படும், இதில் mitmproxy-ca-cert.pem என்பது அதற்கான certificate ஆகும். நீங்கள் agent-ஐத் தொடங்கும் shell-ல், client-ஐ அந்த proxy மற்றும் certificate-ஐ நோக்கிச் சுட்டிக்காட்டவும்.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

பல agent CLI-கள் Node நிரல்களாக உள்ளன. process தொடங்கும் போது Node NODE_EXTRA_CA_CERTS-ஐ வாசிக்கும், எனவே agent-ஐத் தொடங்குவதற்கு முன்பே இதை export செய்யவும்; மற்றொரு terminal-ல் பிறகு செய்ய வேண்டாம். Python client-கள் REQUESTS_CA_BUNDLE அல்லது SSL_CERT_FILE-ஐ வாசிக்கும், Linux-ல் standard library-ஐப் பயன்படுத்தும் Go binary SSL_CERT_FILE-ஐ வாசிக்கும். agent-ஐக் குறை கூறுவதற்கு முன், curl மூலம் அந்தப் பாதை (path) சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்தவும்.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

சரியாகச் செயல்படும் proxy 200-ஐக் காட்டும், மேலும் அந்த request mitmdump-ன் output-ல் தோன்றும். நம்பகத்தன்மையற்ற CA curl: (60) SSL certificate problem: self-signed certificate in certificate chain-ஐக் கொடுக்கும், Node agent-லிருந்து வரும் அதே பிழை SELF_SIGNED_CERT_IN_CHAIN என்ற குறியீட்டைக் கொண்டிருக்கும். சேமிக்கப்பட்ட flows-ஐப் பிறகு console viewer மூலம் படிக்கலாம்; அங்கு ஒரு request-ஐத் திறந்து அதன் headers மற்றும் body-ஐப் பார்க்க முடியும்.

mitmproxy -r /tmp/agent-flows.mitm

நான்கு முடிவுகளைக் குறிப்பிடுவது அவசியம். நீங்கள் request-களைப் பார்க்கிறீர்கள் என்றால், அவற்றை வாசித்து முடிவெடுக்கவும். certificate பிழையுடன் agent தொடங்க மறுத்தால், அது அந்த runtime-ல் உள்ள trust சிக்கலே தவிர, vendor குறித்த கண்டுபிடிப்பு அல்ல. நீங்கள் model API-ஐ மட்டும் பார்க்கிறீர்கள் என்றால், மற்ற பிரிவுகள் முடக்கப்பட்டுள்ளன அல்லது நீங்கள் தூண்டாத ஒரு நிகழ்வில் அவை செயல்படுகின்றன என்று பொருள். அல்லது agent வேலை செய்தாலும் நீங்கள் எதையும் பார்க்கவில்லை என்றால், அந்த client proxy environment variables-ஐப் புறக்கணிக்கிறது அல்லது அதன் certificate-களைப் பிணைத்துள்ளது (pinning) என்று பொருள்; எந்தவொரு application அமைப்பும் உங்களுக்கு உண்மையைச் சொல்லும் என்று நம்ப முடியாது. அந்த கடைசி முடிவுதான் மிக முக்கியமானது, அது உங்களை மீண்டும் படி 3-க்கு அழைத்துச் செல்லும், ஏனெனில் packet capture மூலம் ஒரு இணைப்பைக் கண்டறிவதைத் தவிர்க்க முடியாது.

கட்டுப்பாடுகள், பலவீனமானதிலிருந்து வலிமையானவை வரை

Opt-out அமைப்புகள். இவை மிகவும் மலிவானவை மற்றும் பலவீனமானவை. ஏனெனில், விற்பனையாளர் இவற்றை மதித்து நடப்பதையும், ஏற்கனவே உள்ள ஒரு வகையை இவை உள்ளடக்குவதையும் பொறுத்தே இவை செயல்படுகின்றன. இவை reboot மற்றும் புதிய terminal-க்கு பிறகும் நீடிக்கும் வகையில், user settings file-ல் அல்லது உங்கள் shell profile-ல் அமைக்கவும். நீங்கள் அங்கு இருக்கும்போது DO_NOT_TRACK=1-ஐச் சேர்க்கவும்: இது பல command line கருவிகள் மதிக்கும் ஒரு மரபாகும், சில agents-உம் இதில் அடங்கும். இதற்கு எந்தச் செலவும் இல்லை. அடுத்த update-க்கு பிறகு step 3-ஐ மீண்டும் இயக்கவும், ஏனெனில் அந்த நேரத்தில்தான் coverage மாறுகிறது.

Egress கட்டுப்பாடு. இங்கே நீங்கள் கோருவதை நிறுத்திவிட்டு, அமல்படுத்தத் தொடங்குகிறீர்கள். Agent-ஐ அதன் சொந்த user-ஆக இயக்கவும், பிறகு அந்த user-க்கு loopback மற்றும் DNS-ஐ மட்டும் அனுமதித்து மற்றவற்றைத் தவிர்க்கவும் (drop). இது தனக்கென ஒரு table-ஐச் சேர்ப்பதால், ஏற்கனவே உள்ள firewall விதிகளை இது பாதிக்காது.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

இதை sudo nft -f /etc/nftables.d/agent.nft மூலம் அமல்படுத்தவும், sudo nft list table inet agentegress மூலம் counter-ஐக் கண்காணிக்கவும், sudo journalctl -k -g agent-egress-drop மூலம் drop செய்யப்பட்டவற்றை வாசிக்கவும். நீங்கள் எதிர்பார்க்காத ஒரு hostname-உடன் drop counter அதிகரிப்பதுதான் இந்தச் செயல்பாட்டின் முக்கிய நோக்கமே. இரண்டு நேர்மையான வரம்புகள் உள்ளன. meta skuid என்பது socket-க்கு உரிமையாளராக இருக்கும் user-உடன் பொருந்தும், எனவே அந்த account மற்றொரு user-ஆக மாற முடியாத வரை மட்டுமே இது செயல்படும்: agent-க்கு passwordless sudo என்பது இந்த விதியை ஒரு பரிந்துரையாக மாற்றிவிடும். மேலும், UDP 53-ஐ எந்த server-க்கும் திறந்து வைப்பது, query names மூலம் தரவை வெளியேற்றும் ஒரு பாதையை விட்டுவிடுகிறது. எனவே, உங்கள் threat model-க்கு அது தேவைப்பட்டால், agent-ன் resolver-ஐ நீங்கள் இயக்கும் ஒரு host-க்குச் சுட்டிக்காட்டி அதையும் மூடிவிடவும். Hostname allowlists-ஐ nftables-ல் வைப்பதை விட proxy-ல் வைப்பதே சிறந்தது, ஏனெனில் API endpoints-கள் content delivery networks-க்கு பின்னால் இருப்பதால், அவற்றின் IP addresses அடிக்கடி மாறக்கூடும். இந்தக் கட்டுப்பாட்டின் விலை, சேவைகள் முடங்குவதும் பராமரிப்புமே ஆகும்: package installs, SSH வழியாக git மற்றும் agent-ன் சொந்த update check என அனைத்தும் நீங்கள் அனுமதிக்கும் வரை தோல்வியடையும். அந்தப் பட்டியலைப் பராமரிக்கும் பொறுப்பு இப்போது உங்களுடையது. நீங்கள் இதை ஒரு laptop-ல் அல்லாமல் server-ல் அமைப்பதாக இருந்தால், அதே account மற்றும் firewall அமைப்புதான் running Claude Code safely on a VPS-ன் அடிப்படையாகும்.

Disposable machine. Agent-க்கு ஒரு virtual machine (VM)-ஐ வழங்கவும். அதில் நீங்கள் கவலைப்படும் எந்த credentials-உம் இருக்கக்கூடாது, மேலும் பணியின் முடிவில் அது அழிக்கப்பட வேண்டும். இது agent அனுப்பும் தரவைக் குறைக்காது, மாறாக agent எதை அனுப்ப அணுகல் பெற்றுள்ளது என்பதைக் குறைக்கிறது. இதுவே நீங்கள் உண்மையில் கவலைப்பட வேண்டிய அபாயமாகும். இதை மேலே உள்ள egress விதிகளுடன் இணைக்கவும், ஏனெனில் கட்டுப்பாடற்ற internet access கொண்ட ஒரு புதிய VM கூட உங்கள் capture-ல் உள்ள ஒவ்வொரு host-ஐயும் சென்றடைய முடியும். இந்த முறை மற்றும் ஒவ்வொரு முறையும் நீங்கள் மீண்டும் உருவாக்க வேண்டிய state ஆகியவை running coding agents in a disposable VM-லும், sizing தொடர்பான கேள்வி running a coding agent on a VPS-லும் விளக்கப்பட்டுள்ளன.

Self-hosting the model. Inference flow-ஐ நீக்கும் ஒரே கட்டுப்பாடு இதுதான், ஏனெனில் prompt உங்கள் hardware-ஐ விட்டு வெளியேறாது. இதற்கான விலை அதிகம்: closed model-ஐ உங்களால் self-host செய்ய முடியாது, எனவே open weights-ஐத் தேர்ந்தெடுத்து கடினமான பணிகளில் திறன் குறைபாட்டை ஏற்றுக்கொள்ள வேண்டும், அத்துடன் அவற்றை இயக்கத் தேவையான hardware-உம் தேவை. இந்தச் சமரசம் whether you can self-host Claude-லும், முக்கிய agents-க்கு இடையிலான திறன் வேறுபாடுகள் how Claude Code, Cursor, Codex and Copilot differ-லும் விவாதிக்கப்பட்டுள்ளன.

இந்த நான்கு கட்டுப்பாடுகளில் எதுவுமே, disk-ல் எதை வாசிக்க agent-க்கு அனுமதி உண்டு என்பதை மாற்றாது, மேலும் inference traffic தான் வாசிக்கும் எதையும் எடுத்துச் செல்லும். ஒரு .env file working directory-ல் இருந்தால், agent ஒரு variable name-ஐ grep செய்யும் தருணத்தில் அது model-க்குச் சென்றுவிடும். அந்தத் தகவல்களை எட்டாத தூரத்தில் வைத்திருப்பது ஒரு தனி வேலை, அது keeping secrets out of an AI agent's context-ல் விளக்கப்பட்டுள்ளது.

ஒவ்வொரு update-க்கு பிறகும் சரிபார்க்க வேண்டியவை

1. vendor-ன் settings மற்றும் data usage பக்கங்களை, நீங்கள் கடைசியாகப் பதிவு செய்தவற்றுடன் ஒப்பிட்டுப் பாருங்கள். புதிய switches மற்றும் புதிய named services ஏதேனும் உள்ளதா என்று கவனிக்கவும்.
2. /proc/<pid>/environ-லிருந்து process environment-ஐ மீண்டும் வாசித்து, நீங்கள் செய்த opt-outs தற்போதைய running process-ல் இன்னும் அமலில் உள்ளதா என்பதை உறுதிப்படுத்தவும்.
3. project settings கோப்புகளை மீண்டும் print செய்யவும். ஏனெனில், ஒரு git pull மூலம் உங்கள் சக ஊழியர் மாற்றியமைத்த config கோப்பு உள்ளே வரக்கூடும்.
4. ஒரு முழுமையான real work session-க்கு SNI capture-ஐ இயக்கவும். அதில் உள்ள hostname பட்டியலை உங்கள் முந்தைய பட்டியலுடன் ஒப்பிடவும்.
5. firewall drop counter-ஐச் சரிபார்க்கவும். பொதுவாக, புதிய destination-கள் மற்ற இடங்களுக்குத் தெரியும் முன்பே அங்குதான் தோன்றும்.

இதற்கு சுமார் பத்து நிமிடங்கள் ஆகும். இந்தச் செயல்முறையின் மற்ற பகுதிகள் காலாவதியாகிவிடும், ஆனால் இது மட்டும் காலாவதியாகாது. ஆகஸ்ட் 2026-ல் நீங்கள் சரிபார்த்த ஒரு default அமைப்பு, ஆகஸ்ட் 2026-க்கான உண்மை மட்டுமே. ஆனால், இந்த capture இன்றைய நிலையை விளக்கும் உண்மை.

FAQ

எனது coding agent எனது code-ஐ model-க்கு அனுப்புவதைத் தடுக்க முடியுமா?

முடியாது. அவ்வாறு செய்வதாகக் கூறும் எந்தவொரு அமைப்பும் (setting) வேறொரு விஷயத்தையே குறிக்கிறது. உங்கள் prompt, agent வாசித்த கோப்புகள் மற்றும் அது இயக்கிய கட்டளைகளின் வெளியீடு ஆகியவற்றை model endpoint-க்கு அனுப்புவதுதான் inference செயல்பாட்டின் அடிப்படை. எனவே, யார் அதைப் பெறுகிறார்கள் என்பது மட்டுமே மாறுபடும். agent-ஐ ஒரு நிறுவனத்தின் cloud கணக்கிற்கோ அல்லது நீங்கள் சொந்தமாக host செய்யும் model-க்கோ திருப்புவதன் மூலம் பெறுநரை மாற்றலாம். அது எதைப் படிக்க அனுமதிக்கப்படுகிறது என்பதைக் கட்டுப்படுத்துவதன் மூலம் அனுப்பப்படும் தரவின் அளவைக் குறைக்கலாம். analytics மற்றும் error reporting-ஐ முடக்குவது இந்தச் செயல்பாட்டில் எந்த மாற்றத்தையும் ஏற்படுத்தாது.

எனது coding agent எந்தெந்த host-களுடன் இணைகிறது என்பதை நான் எப்படி அறிவது?

agent-ஐத் தனி Linux user-ஆக இயக்கவும். பின்னர், நீங்கள் அதைப் பயன்படுத்தும்போது ஒவ்வொரு புதிய இணைப்பின் TLS ClientHello-வையும் sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name மூலம் capture செய்யவும். ஒவ்வொரு இணைப்பிற்கும் ஒரு வரி தோன்றும்; அதில் சேருமிட முகவரி (destination address) மற்றும் கோரப்பட்ட hostname இருக்கும். sudo tcpdump -ni any 'udp port 53' மூலம் பெயர்களைச் சரிபார்க்கவும். 127.0.0.53-ல் உள்ள local resolver stub முதலில் query-ஐக் கையாளுவதால், any-ல் capture செய்யவும். agent உண்மையான வேலையைச் செய்யும்போது capture செய்யவும், ஏனெனில் startup pings மற்றும் crash reports போன்றவை idle நிலையில் இருக்கும்போது தெரியாது.

agent வேலை செய்யும்போது எனது proxy-ல் traffic எதுவும் தெரியவில்லை. என்ன தவறு?

ஒன்று, client HTTP_PROXY மற்றும் HTTPS_PROXY-ஐப் புறக்கணிக்கிறது, அல்லது அது அதன் certificates-ஐ pin செய்து உங்கள் CA-வை நிராகரிக்கிறது. முதலில் curl மூலம் பாதையைச் சோதிக்கவும்: curl அந்த proxy வழியாக internet-ஐ அடைந்தும், flow list-ல் agent தெரியவில்லை என்றால், agent proxy environment variables-ஐப் பயன்படுத்தவில்லை என்று அர்த்தம். சில runtimes-க்கு CA ஒரு குறிப்பிட்ட முறையில் வழங்கப்பட வேண்டும். குறிப்பாக Node, NODE_EXTRA_CA_CERTS-ஐ process தொடங்கும் போது மட்டுமே வாசிக்கும், எனவே agent-ஐத் தொடங்கிய பிறகு அதை export செய்வதால் எந்தப் பயனும் இல்லை. proxy-ஆல் traffic-ஐப் பார்க்க முடியாவிட்டால், packet capture முறைக்கு மாறவும்; இதை எந்த application அமைப்பாலும் தவிர்க்க முடியாது.

telemetry-ஐ முடக்குவது எனது code பயிற்சியளிக்கப் பயன்படுத்தப்படுவதைத் தடுக்குமா?

இல்லை. Analytics மற்றும் crash reporting ஆகியவை inference-லிருந்து வேறுபட்டவை. எனவே, அவற்றை முடக்குவது usage counters மற்றும் stack traces-ஐ மட்டுமே நீக்கும்; ஒவ்வொரு prompt-ம் வழக்கம்போலவே model-க்குச் செல்லும். அந்த prompt-கள் சேமிக்கப்படுமா மற்றும் அவை எதிர்கால model-க்கு பயிற்சியளிக்கப்படுமா என்பது உங்கள் plan-ன் விதிமுறைகளைப் பொறுத்தது. consumer plans மற்றும் commercial plans பொதுவாக மாறுபடும். இது packet capture செய்வதை விட, ஒப்பந்தத்தைப் படித்துப் புரிந்துகொள்ள வேண்டிய விஷயம். எனவே, உங்கள் plan-க்கான data usage பக்கத்தைச் சரிபார்க்கவும். தேவைப்பட்டால், முதல் session-க்கு முன்பே commercial அல்லது zero-retention ஒப்பந்தத்தைச் செய்துகொள்ளவும்.